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Praise for Head First OOA&D 


“Head First Object-Oriented Analysis and Design is a refreshing look at the subject of OOA&D. What sets 
this book apart is its focus on learning. There are too many books on the market that spend a lot of 
time telling you why, but do not actually enable the practitioner to start work on a project. Those books 
are very interesting, but not very practical. I strongly believe that the future of software development 
practice will focus on the practitioner. The authors have made the content of OOA&D accessible and 
usable for the practitioner ’’ 

— Ivar Jacobson, Ivar Jacobson Consulting 


“I just finished reading HF OOA&D, and I loved it! The book manages to get across the essentials of 
object-oriented analysis and design with UML and use cases, and even several lectures on good software 
design, all in a fast-paced, easy to understand way. The thing I liked most about this book was its focus 
on why we do OOA&D — to write great software! By defining what great software is and showing how 
each step in the OOA&D process leads you towards that goal, it can teach even the most jaded Java 
programmer why OOA&D matters. This is a great 'first book’ on design for anyone who is new to Java, 
or even for those who have been Java programmers for a while but have been scared off by the massive 
tomes on OO Analysis and Design.” 

— Kyle Brown, Distinguished Engineer, IBM 

“Finally a book on OOA&D that recognizes that the UML is just a notation and that what matters when 
developing software is taking the time to think the issues through.” 

— Pete McBreen, Author, Software Craftsmanship 

“The book does a good job of capturing that entertaining, visually oriented, 'Head First’ writing style. 
But hidden behind the funny pictures and crazy fonts is a serious, intelligent, extremely well-crafted 
presentation of OO Analysis and Design. This book has a strong opinion of how to design programs, 
and communicates it effectively. I love the way it uses running examples to lead the reader through the 
various stages of the design process. As I read the book, I felt like I was looking over the shoulder of an 
expert designer who was explaining to me what issues were important at each step, and why.” 

— Edward Sciore 5 Associate Professor, Computer Science Department 
Boston College 


“This is a well-designed book that delivers what it promises to its readers: how to analyze, design, and 
write serious object-oriented software. Its contents flow effortlessly from using use cases for capturing 
requirements to analysis, design, implementation, testing, and iteration. Every step in the development 
of object-oriented software is presented in light of sound software engineering principles. The examples 
are clear and illustrative. This is a solid and refreshing book on object-oriented software development.” 


— Dung Zung Nguyen，Lecturer 
Rice University 



Praise for other Head First books by the authors 


“When arriving home after a 10-hour day at the office programming, who has the energy to plow 
through yet another new facet of emerging technology? If a developer is going to invest free time in 
self-driven career development, should it not be at least remotely enjoyable? Judging from the content of 
O’Reilly’s new release Head Rush Ajax, the answer is yes.. .Head Rush Ajax is a most enjoyable launchpad 
into the world of Ajax web applications, well worth the investment in time and money.” 

— Barry Hawkins, Slashdot.org 


“By starting with simple concepts and examples, the book gently takes the reader from humble 
beginnings to (by the end of the book) where the reader should be comfortable creating Ajax-based 
websites... Probably the best web designer centric book on Ajax.” 

— Stefan Mischook, Killersites.com 


“Using the irreverent style common of the Head First/Head Rush series of books, this book starts at the 
beginning and introduces you to all you need to know to be able to write the JavaScript that will both 
send requests to the server and update the page with the results when they are re turned... One of the best 
things about this book (apart form the excellent explanations of how the code works) is that it also looks 
at security issues...If you learn Ajax from this book you are unlikely to forget much of what you learn.” 

— Stephen Chapman, JavaScript.About.com 


“Head Rush Ajax is the book if you want to cut through all the hype and learn how to make your web apps 
sparkled.. .your users will love you for it!’’ 

— Kristin Stromberg, Aguirre International 


“If you know some HTML, a dollop of CSS, a little JavaScript, and a bit of PHP, but you’re mystified 
about what all the Ajax hype is about, this book is for you. • .You’ll have a blast learning Ajax with Head 
Rush Ajax. By the time you’ve reached the end of the book, all those web technologies that didn’t quite 
fit together in your head will all snap into place and you’ll have The Ajax Power! You’ll know the secrets 
behind some of the most popular web applications on the Internet. You’ll impress your friends and co¬ 
workers with you knowledge of how those interactive maps and web forms really work.” 

— Elisabeth Freeman, The Walt Disney Internet Group 

Co-Author, Head First Design Patterns and Head First HTML with CSS & XHTML 


“If you thought Ajax was rocket science, this book is for you. Head Rush Ajax puts dynamic, compelling 
experiences within reach for every web developer.’’ 

— Jesse James Garrett, Adaptive Path 


“This stuff is brain candy; I can’t get enough of it.” 

— Pauline McNamara, Center for New Technologies and Education 
Fribourg University, Switzerland 


Praise for other Head First Books 


“I *heart* Head First HTML with CSS & XHTML — it teaches you everything you need to learn in a Tun 
coated’ format!” 

—— Sally Applin, UI Designer and Fine Artist, http:/ / sally.com. 


“My wife stole the book. She’s never done any web design, so she needed a book like Head First HTML 
with CSS & XHTML to take her from beginning to end. She now has a list of web sites she wants to build 
— for our son’s class, our family, ... If I’m lucky, I’ll get the book back when she’s done.” 

_ David Kaminsky, Master Inventor, IBM 

“Freeman’s Head First HTML with CSS & XHTML is a most entertaining book for learning how to build 
a great web page. It not only covers everything you need to know about HTML, CSS, and XHTML, 
it also excels in explaining everything in layman’s terms with a lot of great examples. I found the book 
truly enjoyable to read, and I learned something new!” 

—— Newton Lee, Editor-in-Chief, ACM Computers in Entertainment 
http:/ / www. acmcie. org 


From the awesome Head First Java folks, this book uses every conceivable trick to help you understand 
and remember. Not just loads of pictures: pictures of humans, which tend to interest other humans. 
Surprises everywhere. Stories, because humans love narrative. (Stories about things like pizza and 
chocolate. Need we say more?) Plus, it’s darned funny. 

— Bill Camarda, READ ONLY 


“This book’s admirable clarity, humor and substantial doses of clever make it the sort of book that helps 
even non-programmers think well about problem-solving.” 

—— Cory Doctorow, co-editor of Boing Boing 

Author, “Down and Out in the Magic Kingdom” 

and “Someone Comes to Town, Someone Leaves Town” 

“I feel like a thousand pounds of books have just been lifted off of my head.” 

—— Ward Cunningham, inventor of the Wiki 
and founder of the Hillside Group 


“I literally love this book. In fact, I kissed this book in front of my wife.” 


Satish Kumar 
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To all the brilliant people who came up with various ways to 
gather requirements, analyze software, and design code... 


...thanks for coming up with something good enough to 
produce great software, but hard enough that we needed this 
book to explain it all. 


the authors 




Brett McLaughlin is a guitar player who is still struggling 
with the realization that you can’t pay the bills if you’re into 
acoustic fingerstyle blues and jazz. He’s just recently discovered, 
to his delight, that writing books that help people become better 
programmers does pay the bills. He’s very happy about this, as 
are his wife Leigh, and his kids, Dean and Robbie. 

Before Brett wandered into Head First land, he developed 
enterprise Java applications for Nextel Communications and 
Allegiance Telecom. When that became fairly mundane, Brett 
took on application servers, working on the internals of the 
Lutris Enhydra servlet engine and EJB container. Along the 
way, Brett got hooked on open source software, and helped 
found several cool programming tools, like Jakarta Turbine and 
JDOM. Write to him at brett@oreilly.com. 




I Gary Pollice is a self-labeled curmudgeon (that’s a crusty, ill-tempered, 
usually old man) who spent over 35 years in industry trying to figure out 
what he wanted to be when he grew up. Even though he hasn’t grown up yet, 
he did make the move in 2003 to the hallowed halls of academia where he 
has been corrupting the minds of the next generation of software developers 
with radical ideas like, “develop software for your customer, learn how to 
work as part of a team, design and code quality and elegance and correctness 
counts, and it’s okay to be a nerd as long as you are a great one.” 

ary is a Professor of Practice (meaning he had a real job before becoming a 
rofessor) at Worcester Polytechnic Institute. He lives in central Massachusetts 
ith his wife, Vikki, and their two dogs, Aloysius and Ignatius. You can visit 
is WPI home page at http : / /web. cs . wpi . edu/ 〜 gpollice/. Feel free 
o drop him a note and complain or cheer about the book. 


Dave West would like to describe himself as sheik geek. Unfortunately 
no one else would describe him in that way. They would say he is a 
professional Englishman who likes to talk about software development best 
practices with the passion and energy of an evangelical preacher. Recently 
Dave has moved to Ivar Jacobson Consulting, where he runs the Americas 
and can combine his desire to talk about software development and spread 
the word on rugby and football, and argue that cricket is more exciting than 
baseball. 


Before running the Americas for Ivar Jacobson Consulting, Dave worked 
for a number of years at Rational Software (now a part of IBM). Dave held 
many positions at Rational and then IBM, including Product Manager for 
RUP where he introduced the idea of process plug-ins and agility to RUP. 
Dave can be contacted at dwest@ivarjacobson.com. ^ 
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Great Software Begins Here 

So how do you really write great software? it s never easy trying 
to figure out where to start. Does the application actually do what it’s supposed to? 
And what about things like duplicate code — that can’t be good, can it? It’s usually pretty 
hard to know what you should work on first, and still make sure you don’t screw 
everything else up in the process. No worries here, though. By the time you’re done 
with this chapter, you’ll know how to write great software, and be well on your way 
to improving the way you develop applications forever. Finally, you’ll understand why 
OOAD is a four-letter word that your mother actually wants you to know about. 
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Give Them What They Want 

Everybody loves a satisfied customer. You already know that the first 

step in writing great software is making sure it does what the customer wants it to. But 
how do you figure out what a customer really wants? And how do you make sure that 
the customer even knows what they really want? That’s where good requirements 
come in, and in this chapter, you’re going to learn how to satisfy your customer by 
making sure what you deliver is actually what they asked for. By the time you’re done, 
all of your projects will be “satisfaction guaranteed,” and you’ll be well on your way to 
writing great software, every time. 
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I Love You ， You’re Perfect... Now Change 

Think you’ve got just what the customer wanted? 

I Not SO fast... So you’ve talked to your customer, gathered requirements, written 
out your use cases, and delivered a killer application. It’s time for a nice relaxing 
cocktail, right? Right... until your customer decides that they really wanted something 
different than what they told you. They love what you’ve done, really, but it’s not 
quite good enough anymore. In the real world, requirements are always changing, 
and it’s up to you to roll with these changes and keep your customer satisfied. 
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Taking Your Software into the Real World 

It’s time to graduate to real-world applications. 

I Your application has to do more than work on your own personal development machine, 


finely tuned and perfectly setup; your apps have to work when real people use them. 
This chapter is all about making sure that your software works in a real-world context 
You’ll learn how textual analysis can take that use case you’ve been working on and 
turn it into classes and methods that you know are what your customers want. And 


when you’re done, you too can say: “I did it! My software is ready for the real world!” 
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Nothing Ever Stays the Same 

Change is inevitable. No matter how much you like your software right 
now, it’s probably going to change tomorrow. And the harder you make it for 
your software to change, the more difficult it’s going to be to respond to your 
customer’s changing needs. In this chapter, we’re going to revisit an old friend, 
try and improve an existing software project, and see how small changes can 
turn into big problems. In fact, we’re going to uncover a problem so big that it will 
take a TWO-PART chapter to solve it! 
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5 (part 2) 


good design 二 flexible software 

Give Your Software a 30-minute Workout 

Ever wished you were just a bit more flexible? 

When you run into problems making changes to your application, it probably 
means that your software needs to be more flexible and resilient. To help stretch 
your application out, you’re going to do some analysis, a whole lot of design, and 
learn how 00 principles can really loosen up your application. And for the grand 
finale, you’ll see how higher cohesion can really help your coupling. Sound 
interesting? Turn the page, and let’s get back to fixing that inflexible application. 
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“My Name is Art Vandelay... I am an Architect” 

It’s time to build something REALLY BIG. Are you ready? 

You’ve got a ton of tools in your OOA&D toolbox, but how do you use those tools 
when you have to build something really big? Well, you may not realize it, but 
you’ve got everything you need to handle big problems. We’ll learn about some 
new tools, like domain analysis and use case diagrams, but even these new tools 
are based on things you already know about — like listening to the customer and 
understanding what you’re going to build before you start writing code. Get ready... 
it’s time to start playing the architect. 


Solving big problems 

It’s all in how you look at the big problem 

Requirements and use cases are a good place to start... 

Commonality and variability 

Figure out the features 

The difference between features and requirements 


a swallcv ^voV>lcr« «-U 



Small 


Problem 


Small 


Problem 


Big 

Problem 


Use cases don’t always help you see the big picture 
Use case diagrams 
The Little Actor 

Actors are people, too (well, not always) 

Let’s do a little domain analysis 
Divide and conquer 
Don’t forget who the customer really is 
What’s a design pattern? 

The power of OOA&D (and a little common sense) 
OOA&D Toolbox 


280 

281 

286 

287 

290 

292 

294 

296 

301 

302 
307 
309 
313 
315 
318 
320 


XVI 






table of contents 



7 Bringing Order to Chaos 

You have to start somewhere, but you better pick the right 

Somewhere! You know how to break your application up into lots of small 
problems, but all that means is that you have LOTS of small problems. In this chapter, 
we’re going to help you figure out where to start, and make sure that you don’t waste 
any time working on the wrong things. It’s time to take all those little pieces laying 
around your workspace, and figure out how to turn them into a well-ordered, well- 
designed application. Along the way, you’ll learn about the all-important 3 Qs of 
architecture, and how Risk is a lot more than just a cool war game from the ‘80s. 
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Originality is Overrated 

Imitation is the sincerestform of not being stupid. Theres 

nothing as satisfying as coming up with a completely new and original solution to a 
problem that’s been troubling you for days — until you find out someone else solved 
the same problem, long before you did, and did an even better job than you did! In 
this chapter, we’re going to look at some design principles that people have come up 
with over the years, and how they can make you a better programmer. Lay aside your 
thoughts of “doing it your way ”； this chapter is about doing it the smarter, faster way. 
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The Open-Closed Principle (OGP) 
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The Software is Still for the Customer 

It’s time to show the customer how much you really care. 

Nagging bosses? Worried clients? Stakeholders that keep asking, “Will it be done on 
time?” No amount of well-designed code will please your customers; you’ve got to 
show them something working. And now that you’ve got a solid 00 programming 
toolkit, it’s time to learn how you can prove to the customer that your software 
works. In this chapter, we learn about two ways to dive deeper into your software’s 
functionality, and give the customer that warm feeling in their chest that makes them 
say, Yes, you’re definitely the right developer for this job! 
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Putting It All Together 

Are We there yet? WeVe been working on lots of individual ways to 
improve your software, but now it’s time to put it all together. This is it, what 
you’ve been waiting for: we’re going to take everything you’ve been learning, 
and show you how it’s all really part of a single process that you can use over 
and over again to write great software. 
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appendix i ： le&Vers 

The Top Ten Topics (we didn’t cover) 

Believe it or not, there’s still more. Yes, with over 550 

pages under your belt, there are still things we couldn’t cram in. Even 
though these last ten topics don’t deserve more than a mention, we didn’t 
want to let you out of Objectville without a little more information on each 
one of them. But hey, now you’ve got just a little bit more to talk about 
during commercials of CATASTROPHE... and who doesn’t love some 
stimulating OOA&D talk every now and then? 


Anti Patterns 

Anti-patterns are the 二 。二二 

be recognized and avoided. 


#1.IS-A and HAS-A 

558 

#2. Use case formats 
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appendix ii: welcome fe objectVille 

Speaking the Language of OO 

Get ready to take a trip to a foreign country, it s time to 

visit Objectville, a land where objects do just what they’re supposed to, 
applications are all well-encapsulated (you’ll find out exactly what that means 
shortly), and designs are easy to reuse and extend. But before we can get 
going, there are a few things you need to know first, and a little bit of language 
skills you’re going to have to learn. Don’t worry, though, it won’t take long, and 
before you know it, you’ll be speaking the language of OO like you’ve been 
living in the well-designed areas of Objectville for years. 
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how to use this book 


Who is this book for? 


If you can answer “yes” to all of these: 

Do you know Java? (You don’t need to be a guru.) 

(2) Do you want to learn, understand, remember, and 
apply object-oriented analysis and design to real world 
projects, and write better software in the process? 

(3) Do you prefer stimulating dinner party conversation 

to dry, dull, academic lectures? 

this book is for you. 


Who should probably back away from this book? 

If you can answer “yes” to any one of these: 

Are you completely new to Java? (You don’t need to 
be advanced, and even if you don’t know Java, but 
you know C#, you’ll probably understand almost all 
of the code examples. You also might be okay with 
just a C++ background.) 

^2) Are you a kick-butt 00 designer/developer looking 
for a reference book? 


(3) Are you afraid to try something different? Would 
you rather have a root canal than mix stripes 
with plaid? Do you believe that a technical book 
can’t be serious if programming concepts are 
anthropomorphized? rt 


this book is not for you. 
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Wc know what you're thmkmg. 
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How can this be a serious programming book? 
What’s with all the graphics?” 

Can I actually learn it this way?” 


55 


And we know what your brain is thmkmg. 

Your brain craves novelty. It’s always searching, scanning, waiting for 
something unusual. It was built that way, and it helps you stay alive. 

So what does your brain do with all the routine, ordinary, normal things 
you encounter? Everything it can to stop them from interfering with the 
brain’s 韻 /job —— recording things that matter. It doesn’t bother saving 
the boring things; they never make it past the “this is obviously not 
important” filter. 

How does your brain know what’s important? Suppose you’re out 
for a day hike and a tiger jumps in front of you, what happens inside 
your head and body? 

Neurons fire. Emotions crank up. Chemicals surge. 

And that’s how your brain knows... 

This must be important! Don’t forget it! 

But imagine you’re at home, or in a library. It’s a safe, warm, tiger-free zone. 
You’re studying. Getting ready for an exam. Or trying to learn some tough 
technical topic your boss thinks will take a week, ten days at the most. 

Just one problem. Your brain’s trying to do you a big favor. It’s trying to 
make sure that this obviously non-important content doesn’t clutter up scarce 
resources. Resources that are better spent storing the really big things. Like 
tigers. Like the danger of fire. Like how you should never again 
snowboard in shorts. 

And there’s no simple way to tell your brain, “Hey brain, thank you 
very much, but no matter how dull this book is, and how little I’m 
registering on the emotional Richter scale right now, I really do want 
you to keep this stuff around.” 
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Metacognition: thinking about thinking 

If you really want to learn, and you want to learn more quickly and more 
deeply, pay attention to how you pay attention. Think about how you think. 

Learn how you learn. 

Most of us did not take courses on metacognition or learning theory when we 
were growing up. We were expected to learn, but rarely taught to learn. 

But we assume that if you’re holding this book, you really want to learn object- 
oriented analysis and design. And you probably don’t want to spend a lot of 
time. And since you’re going to develop software, you need to remember what you 
read. And for that, you’ve got to understand it. To get the most from this book, or 
any book or learning experience, take responsibility for your brain. Your brain 
on this content. 

The trick is to get your brain to see the new material you’re learning as 
Really Important. Crucial to your well-being. As important as a tiger. 

Otherwise, you’re in for a constant battle, with your brain doing its best to 
keep the new content from sticking. 

So just how DO you get your brain to think object- 
oriented analysis and design is a hungry tiger? 

There’s the slow, tedious way, or the faster, more effective way. The slow 
way is about sheer repetition. You obviously know that you are able to 
learn and remember even the dullest of topics if you keep pounding the same thing 
into your brain. With enough repetition, your brain says, “This doesn’t feel important to 
him, but he keeps looking at the same thing over and over and over, so I suppose it must be. 
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The faster way is to do anything that increases brain activity^ especially different 
types of brain activity. The things on the previous page are a big part of the solution, 
and they’re all things that have been proven to help your brain work in your favor. For 
example, studies show that putting words within the pictures they describe (as opposed to 
somewhere else in the page, like a caption or in the body text) causes your brain to try to 
makes sense of how the words and picture relate, and this causes more neurons to fire. 
More neurons firing = more chances for your brain to get that this is something worth 
paying attention to, and possibly recording. 


A conversational style helps because people tend to pay more attention when they 
perceive that they’re in a conversation, since they’re expected to follow along and hold up 
their end. The amazing thing is, your brain doesn’t necessarily care that the “conversation” 
is between you and a book! On the other hand, if the writing style is formal and dry, your 
brain perceives it the same way you experience being lectured to while sitting in a roomful 
of passive attendees. No need to stay awake. 

But pictures and conversational style are just the beginning. 
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Here's what WE did: 


We used pictures, because your brain is tuned for visuals, not text. As far as your 
brain’s concerned, a picture really is worth 1,024 words. And when text and pictures 
work together, we embedded the text in the pictures because your brain works more 
effectively when the text is within the thing the text refers to, as opposed to in a caption 
or buried in the text somewhere. 


O 


We used redundancy^ saying the same thing in different ways and with different media types, 
and multiple senses : to increase the chance that the content gets coded into more than one area of 
your brain. 



We used concepts and pictures in unexpected ways because your brain is tuned for novelty, 
and we used pictures and ideas with at least some emotional content, because your brain is 
tuned to pay attention to the biochemistry of emotions. That which causes you to feel something 
is more likely to be remembered, even if that feeling is nothing more than a little humor, 
surprise, or interest. 

We used a personalized, conversational style, because your brain is tuned to pay more 
attention when it believes you’re in a conversation than if it thinks you’re passively listening to a 
presentation. Your brain does this even when you’re reading. 

We included more than 80 activities, because your brain is tuned to learn and remember 
more when you do things than when you read about things. And we made the exercises 
challenging-yet-do-able, because that’s what most people prefer. 

We used multiple learning styles, becausejoz/ might prefer step-by-step procedures, while 
someone else wants to understand the big picture first, and someone else just wants to see a 
code example. But regardless of your own learning preference, everyone benefits from seeing the 
same content represented in multiple ways. 
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BULLET POINTS 



We include content for both sides of your brain, because the more of your brain you 
engage, the more likely you are to learn and remember, and the longer you can stay focused. 
Since working one side of the brain often means giving the other side a chance to rest, you can 
be more productive at learning for a longer period of time. 

And we included stories and exercises that present more than one point of view ，because 
your brain is tuned to learn more deeply when it’s forced to make evaluations and judgements. 

We included challenges, with exercises, and by asking questions that don’t always have 
a straight answer, because your brain is tuned to learn and remember when it has to work at 
something. Think about it~you can’t get your body in shape just by watching people at the gym. 
But we did our best to make sure that when you’re working hard, it’s on the right things. That 
you } re not spending one extra dendrite processing a hard-to-understand example, or 
parsing difficult, jargon-laden, or overly terse text. 

We people. In stories, examples, pictures, etc., because, well, because a person. And 
your brain pays more attention to people than it does to things. 

We used an 80/20 approach. We assume that if you’re going for a PhD in software design, this 
won’t be your only book. So we don’t talk about every thing. Just the stuff you’ll actually need. 
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Here's what YOU caw do to bend 
your brain mto submission 

So, we did our part. The rest is up to you. These tips are a starting point; listen to 
your brain and figure out what works for you and what doesn’t. Try new things. 

Cui iWls si\tk H 

咖 youm 


(T) Slow down. The more you understand, 
the less you have to memorize. 

Don’t just read. Stop and think. When the 
book asks you a question, don’t just skip to the 
answer. Imagine that someone really is asking 
the question. The more deeply you force your 
brain to think, the better chance you have of 
learning and remembering. 

Do the exercises. Write your own notes. 

We put them in, but if we did them for you, 
that would be like having someone else do 
your workouts for you. And don’t just look at 
the exercises. Use a pencil. There’s plenty of 
evidence that physical activity while learning 
can increase the learning. 

(§) Read the “There are No Dumb Questions” 

That means all of them. They’re not optional 
side-bars —— they } re part of the core content! 

Don’t skip them. 

(4) Make this the last thing you read before 
bed. Or at least the last challenging thing. 

Part of the learning (especially the transfer to 
long-term memory) happens after you put the 
book down. Your brain needs time on its own, to 
do more processing. If you put in something new 
during that processing time, some of what you 
just learned will be lost. 

(5) Drink water. Lots of it. 

Your brain works best in a nice bath of fluid. 
Dehydration (which can happen before you ever 
feel thirsty) decreases cognitive function. 


(§) Talk about it. Out loud. 

Speaking activates a different part of the brain. 

If you’re trying to understand something, or 
increase your chance of remembering it later, say 
it out loud. Better still, try to explain it out loud 
to someone else. You’ll learn more quickly, and 
you might uncover ideas you hadn’t known were 
there when you were reading about it. 

(7^ Listen to your brain. 

Pay attention to whether your brain is getting 
overloaded. If you find yourself starting to skim the 
surface or forget what you just read, it’s time for a 
break. Once you go past a certain point, you won’t 
learn faster by trying to shove more in, and you 
might even hurt the process. 

( 8 ) Fee# something! 

Your brain needs to know that this matters. Get 
involved with the stories. Make up your own 
captions for the photos. Groaning over a bad joke is 
still better than feeling nothing at all. 

(9) Design something! 

Apply what you read to something new you’re 
designing, or rework an older project. Just do 
something to get some experience beyond the 
exercises and activities in this book. All you need is 
a problem to solve... a problem that might benefit 
from one or more techniques that we talk about. 
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Read Me 

This is a learning experience, not a reference book. We deliberately stripped out 
everything that might get in the way of learning whatever it is we’re working on at that 
point in the book. And the first time through, you need to begin at the beginning, because 
the book makes assumptions about what you’ve already seen and learned. 


We assume you are familiar with Java. 

It would take an entire book to teach you Java (in fact, that’s exactly what it took: Head 
First Java). We chose to focus this book on analysis and design, so the chapters are written 
with the assumption that you know the basics of Java. When intermediate or advanced 
concepts come up, they’re taught as if they might be totally new to you, though. 

If you’re completely new to Java, or coming to this book from a C# or C++ background, 
we strongly recommend you turn to the back of the book and read Appendix II before 
going on. That appendix has some intro material that will help you start this book off on 
the right foot. 

We only use Java 5 when we have to. 

Java 5.0 introduces a lot of new features to the Java language, ranging from generics to 
parameterized types to enumerated types to the foreach looping construct. Since many 
professional programmers are just moving to Java 5, we didn’t want you getting hung up 
on new syntax while you’re trying to learn about OOA&D. In most cases, we stuck with 
pre-Java 5 syntax. The only exception is in Chapter 1, when we needed an enumerated 
type —— and we explained enums in that section in some detail. 

If you’re new to Java 5, you should have no trouble with any of the code examples. If 
you’re already comfortable with Java 5, then you will get a few compiler warnings about 
unchecked and unsafe operations, due to our lack of typed collections, but you should be 
able to update the code for Java 5 on your own quite easily. 


The activities are NOT optional. 

The exercises and activities are not add-ons; they’re part of the core content of the book. 
Some of them are to help with memory, some are for understanding, and some will help 
you apply what you’ve learned. DonH skip the exercises. The crossword puzzles are 
the only things you don’t have to do, but they’re good for giving your brain a chance to 
think about the words and terms you’ve been learning in a different context. 
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The redundancy is intentional and important. 

One distinct difference in a Head First book is that we want you to really get it. And we 
want you to finish the book remembering what you’ve learned. Most reference books 
don’t have retention and recall as a goal, but this book is about learning, so you’ll see some 
of the same concepts come up more than once. 


The examples are as lean as possible. 

Our readers tell us that it’s frustrating to wade through 200 lines of an example looking 
for the two lines they need to understand. Most examples in this book are shown within 
the smallest possible context, so that the part you’re trying to learn is clear and simple. 
Don’t expect all of the examples to be robust, or even complete —— they are written 
specifically for learning, and aren’t always fully-functional. 

In some cases, we haven’t included all of the import statements needed, but we assume 
that if you’re a Java programmer, you know that ArrayList is in java. util, for 
example. If the imports are not part of the normal core J2SE API, we mention it. We’ve 
also placed all the source code on the web so you can download it. You’ll find it at 

http :// www.headfirstlabs.com/books/hfoo/. 

Also, for the sake of focusing on the learning side of the code, we did not put our 
classes into packages (in other words, they’re all in the Java default package). We don’t 
recommend this in the real world, and when you download the code examples from this 
book, you’ll find that all classes are in packages. 


The ( Brain Power’ exercises don’t have answers. 

For some of them, there is no right answer, and for others, part of the learning experience 
of the Brain Power activities is for you to decide if and when your answers are right. In 
some of the Brain Power exercises you will find hints to point you in the right direction. 
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The Technical Team 


Hannibal Sdipio 



Technical Reviewers: 


Huge thanks to our amazing trio of technical reviewers. These guys caug 
that we missed, let us know when we were moving too fast (or too slow), and even 
let us know when our jokes sucked. Several times, they turned chapters around in a 
matter of hours... we’re not sure if that means they’re really helpful, or need to get 
away from software development a little more. Hannibal in particular made our 
week when he let us know that the big OOA&D arrow in Chapter 10 was “Hot!” 
Thanks guys, this book wouldn’t be nearly as solid without your hard work. 


Kathy Sierra and Bert Bates: 

We continue to be amazed at the insight and 
expertise that Bert Bates has about cliffs, and that 
Kathy Sierra has about dog doors. If that doesn’t 
make much sense, don’t be surprised —— everything 
you know about almost everything gets turned on its 
head when you meet this pair, and yet we all came 
out much for the better because of their help. 

Bert and Kathy did a ton of review at the eleventh 
hour, and we’re thankful they did. Their help and 
guidance continues to be the heart of Head First. 
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it’s fair to say she fought more battles and paved the way for us to work 
without interruption more times than any of us really are aware of. Most 
I uportantly, she made this the single most enjoyable project we’ve worked on 
li our careers. Frankly, she kicked our asses a number of times, and it made 
all the difference. She really doesn’t realize how much of an effect she has 
on the people she works with, because we don’t tell her enough how much 
■we respect her and value her opinions. So there, now you know, Mary. If we 
could put your name on the cover, we would (oh, wait... we did!). 


/Vlav^Y 0 ， ?> } r^Y\ 


The O’Reilly team: 


These books are a team effort, never more so than on this one. Mike Hendrickson and Laurie 


Petrycki oversaw this project at various times, and took heated phone calls more than once. 
Sanders Kleinfeld cut his Head First teeth on this project, and managed to come out alive; 
better yet, he did a great job, improving the book, and we all are excited that this is just the first of 
many Head First books he’ll be working on. Mike Loukides found Bert and Kathy way back 


when, and Tim O’Reilly had the foresight to turn their crazy idea into 
a series. As always, Kyle Hart is instrumental in getting these books “out 
there”，and Edie Freedman’s beautiful cover design continues to amaze 
us all. 

A particularly special thanks goes out to Louise Barr, the Head First 
Design Editor. Lou pulled several 12 - and 14-hour days to help us with 
graphics in this book, and put together the amazing Objectville Subway Map 
in Chapter 10. Lou, your work has improved the learning quality of this 
book, and we can’t thank you enough for your contributions. - 

Lou Bav-v- 
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special thanks 


Special thanks 

Near the completion of this book, Laura Baldwin, the CFO of O’Reilly, encountered some 
personal tragedy. It’s hard to know what to say in these situations, especially because Laura has 
really become the backbone of O’Reilly in many ways. Laura, we are thinking and praying for you 
and your family, and we wish you all the very, very best in the days to come. We know you’d want 
nothing more than to see everyone at O’Reilly working harder than ever while you’re away. 

This book is certainly a testament to the people at O’Reilly continuing to deliver, and in many of 
our conversations, your name came up as someone we wanted to support, and not let down in any 
way. Your effect on this company is extraordinary, and O’Reilly and the Head First series will all be 
much better for the day you can return to us in full swing. 
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Intro 


Well-designed apps rock 


Great Software 



I can hardly get over* it, 
Sue, but since I started using 
OOA&O, I'm just a new man... a 
new man, ril tell you! 


Begins Here 


So how do you really write great software? it s never easy 

trying to figure out where to start. Does the application actually do what 


it’s supposed to? And what about things like duplicate code — that can’t be 


good, can it? It’s usually pretty hard to know what you should work on first, 
and still make sure you don’t screw everything else up in the process. No 


worries here, though. By the time you’re done with this chapter, you’ll know 
how to write great software, and be well on your way to improving the way 
you develop applications forever. Finally, you’ll understand why OOA&D is a 
four-letter word that your mother actually wants you to know about. 


this is a new chapter 



















the sounds of wood and steel 


Rock and roll is forever! 

There’s nothing better than the sound of a killer guitar in the hands 
of a great player, and Rick’s Guitars specializes in finding the perfect 
instrument for his discerning customers. 




You wouldtVt believe 
the selection we have here. 
Come on in, tell us about what kind 
of guitar you like, and well find 
you the perfect instrument, 
guaranteed! 


lAtti ^ ^-tav 
aJPidio^ado, ayvd ok 

- ad s—. 


Just a few months ago, Rick decided to throw out his paper-based 
system for keeping track of guitars, and start using a computer-based 
system to store his inventory. He hired a popular programming firm, 
Down and Dirty Coding, and they’ve already built him an inventory 
management app. He’s even had the firm build him a new search 
tool to help him match up a customer to their dream instrument. 
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well-designed apps rock 


Rick's shiny hew application... 

Here’s the application that the programming firm built for Rick... they’ve 
put together a system to completely replace all of Rick’s handwritten 
notes, and help him match his customers with the perfect guitar. Here’s 
the UML class diagram they gave Rick to show him what they did: 


tW«s tlass. —s 


Wc\rc arc 
the variables 
ih the 

^ui-tav dass. 


TV^csc avc 

methods 

tlass. 


serialNumber: String 
price: double 
builder: String 
model: String 
type: String 
backWood: String 
topWood: String 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getBuilder(): String 
getModel(): String 
getType(): String 
getBackWood(): String 
getTopWoodQ: String 


扞饮 ”_ ^ ，s •崎 hWy, 

as wcl1 as a for him -to 1 
+o\r 


T\\t mvcw 
all *bV\c 
6uvvcv\*blY 


,-tovv s-toves a 
available- 



addGuitar(String, double, String, String, String, 
String, String) 
getGuitar(String): Guitar 
search(Guitar): Guitar 


丁 W，s method 
-takes a 
sevidl , 

—tav 、 obje 乙 t. 


?| S ! S ^ihod ； 

丄 ” ahd , cW 

•^ve ， W y ih3i up 

spe 匕 s. 


I his ^cihod 

十 s i“i 

y 3 

dc ^ ^C3ics 

3 dds ii i, 
K,6ks 


wi & ihe die^ 


K\ck deeded tV>csc ayrC .J^f::3 a U，Wt 


New to Objectville? 


^ vc ^ Somc ^ 

' h 烀 p^x a,ck n ou / 

9 oih 9 ^ ^ youVe 


If you’re new to object oriented programming, haven’t heard of UML before, 
or aren’t sure about the diagram above, it’s OK! We’ve prepared a special 
“Welcome to Objectville” care package for you to get you started. Flip to the 
back of the book, and read Appendix II — we promise you’ll be glad you did. 
Then come back here, and this will all make a lot more sense. 


you are here ► 


3 













rick’s initial application code 


Here what the code for 
ftuitar.java looks like 


You’ve seen the class diagram for Rick’s application on the last 
page; now let’s look at what the actual code for Guitar. java 
and Inventory. java look like. 


public class Guitar { 


.. ( wc saw 

， d3ss. 
kC 


private String serialNumber, builder, model, type, backWood, topWood; 
private double price; 


public Guitar(String serialNumber, double price. 

String builder, String model, String type , 
String backWood, String topWood) { 
this.serialNumber = serialNumber; 


this.price = price; 
this.builder = builder; 
this.model = model; 
this.type = type; 
this.backWood = backWood; 
this.topWood = topWood; 


UML dass diayams do 於七 
siioy/ £.oK\s*t\rut*tov-s ； ^uitav- 

docs jus 七 4a 七 youd 
七 sc*U all mi 七 ial 

pv-opcv-*tics -fov- d v\t>N ^uitav-. 


public String getSerialNumber() { 

return serialNumber; 

} 

public double getPrice () { 

return price; 

} 

public void setPrice(double newPrice) 
this.price = newPrice; 

} 

public String getBuilder() { 

return builder; 


public String getModel() { 

return model; 

} 

public String getType() { 

return type; 

} 

public String getBackWood() 
return backWood; 

} 

public String getTopWood() 
return topWood; 

} 


You see V^ov/ 
i\\t dlass diayaw 

6\yj：\iar class’s dodc. 




serialNumber: String 
price: double 
builder: String 
model: String 
type: String 
backWood: String 
topWood: String 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getBuilder(): String 
getModel(): String 
getType(): String 
getBackWood(): Sti 
getTopWood(): Strin 


class 

Guitar 


tar () 
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well-designed apps rock 


Awd Iwvcwtory.java 

public class Inventory { 
private List guitars; 


public Inventory() { 

guitars = new LinkedList(); 


Rcmcmkcv, v/e’vc 如 ?? cd 
out • 七 址 … is 

{jo save some spade. 


public void addGuitar(String serialNumber, double price. 

String builder. String model. 

String type. String backWood, String topWood) { 
Guitar guitar = new Guitar(serialNumber, price, builder. 


guitars.add(guitar); 


model, type, backWood, topWood); 



public Guitar getGuitar(String serialNumber) { 

for (Iterator i = guitars.iterator (); i.hasNext(); ) { 

Guitar guitar = (Guitar)i.next (); 

if (guitar.getSerialNumber().equals(serialNumber)) { 

return guitar; 


3dds ^ ^ i.v c ， Wy. 


return null; 


public Guitar search(Guitar searchGuitar) { ^ ' 

for (Iterator i = guitars.iterator (); i.hasNext();) 
Guitar guitar = (Guitar)i.next (); 

// Ignore serial number since that's unique 

// Ignore price since that's unique 

String builder = searchGuitar.getBuilder(); 

if ( (builder ! = null) && (! builder . equals ('、’’））&& 

(!builder.equals(guitar.getBuilder()))) 
continue; 

String model = searchGuitar.getModel(); 

if ( (model != null) && (!model • equals ('、〃））&& 

(!model.equals(guitar.getModel()))) 
continue; 


TWis me 七 Vuxi is a brt of a mess 二 

\i o| tKc 

object passed rn ^ 

object m R«^S 



String type = searchGuitar.getType(); 
if ( (type != null) && (! searchGuitar . equals (''〃））&& 

(!type.equals(guitar.getType()))) 


continue; 

String backWood = searchGuitar.getBackWood(); 
if ( (backWood != null) && (!backWood• equals ('、〃））&& 

(!backWood.equals(guitar.getBackWood()))) 
continue; 

String topWood = searchGuitar.getTopWood(); 

if ( (topWood ! = null) && (! topWood. equals (''") ) && 

(!topWood.equals(guitar.getTopWood()))) 
continue; 

} 

return null; 



addGuitar(String, double, String, String, String, 
String, String) 
getGuitar(String): Guitar 
search(Guitar): Guitar 


Inven- h 
tory { 

search () 1 


Inventory.java 
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the case of the missing guitar 


Put thcw Rick started losing customers 


詹 tt 


It seems like no matter who the customer is and what they like, Rick’s new search 
program almost always comes up empty when it looks for good guitar matches. But 
Rick knows he has guitars that these customers would like... so what’s going on? 


t C k S 純 “Uhey like, 


public class FindGuitarTester { 

public static void main(String[] args) { 

// Set up Rick's guitar inventory 
Inventory inventory = new Inventory(); 
initializelnventory(inventory); 

Guitar whatErinLikes = new Guitar ('、〃, 0, ''fender ^, ''Stratocastor ^, 

''electric", ''Alder", ''Alder"); 
Guitar guitar = inventory.search(whatErinLikes); 於 、^ 

if (guitar != null) { W、s U— 

System. out. print In (''Erin, you might like this 〃 + Jf y a 

guitar. getBuilder () + '、" + guitar. getModel () + '、" u ^, 
guitar. getType () + '' guitar : \n ,r + , (T 

0"a 

guitar. getBackWood () + '、 back and sides, \n 〃 + 

guitar. getTopWood () + '' top. \nYou can have it for only $〃 - 
guitar. getPrice () + '、！"）； 

} else { 

System. out. print In (''Sorry, Erin, we have nothing for you . r, ); 



private static void initializelnventory ( 工 nventory inventory) 
// Add guitars to the inventory... 
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well-designed apps rock 



But I know I have a killer 
Fender Strat guitar. Look, ifs 
right here ： 



These spe^s seem 
•bo rnatdh up 
pC\r-Pc^*tly v/i 七 h 
what &r’m asked 


ttevVs pav**t Code *fo\r … so 

七 ha 七 sc*ts uf s mvcy\*tov-y. or\? 

Looks like Kc S ^o-t 

<oV* &rnr\. 


Sharpen your pencil 


How would you redesign Rick’s app? 

Look over the last three pages, showing the code for Rick’s app, and the results 
of running a search. What problems do you see? What would you change? Write 
down the FIRST thing you’d do to improve Rick’s app in the blanks below. 
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how do you write great software? 


Whaf s the FIRST thing you'd change? 


It’s obvious that Rick’s app has problems, but it’s not so obvious what we 
should work on first. And it looks like there’s no shortage of opinion: 


O 


O 






Look at all those Strings! 
Thafs terrible... can’t we use 
constants or objects instead? 

Guitar 


Whoa... these notes from the 
owner says he wants his clients 
to have multiple choices. ShouldiVt 
the search() method return a list of 
matches? 


O 


serialNumber: String 
price: double 
builder: String 
model: String 
type: String 
backWood: String 
topWood: String 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getBuilder(): String 
getModel(): String 
getType(): String 
getBackWood(): String 
getTopWood(): String 


Joes WI7 … 

-to 

w 七 he、a 
v/vrb” object- 

ov»c^*bcd to At- 

rmahk s bcch a^d (oy a 

whi,c ^ ⑹ Hy khows his 00 

P^'^iplcs ahd d«i 9h paUc^hs. 


Inventory 


guitars: List 

addGuitar(String, double, String, String, Stf' 

String, String) 
getGuitar(String): Guitar 
search(Guitar): Guitar 


This design is terrible! The 
Inventory and Guitar classes 
depend on each other too much, and I 
can't see how this is an architecture 
that you’d ever be able to 
build upon. We need some 
q - \ restructuring. 




jars a W aUavs 

dclWcv-'^^ ^ a 


What would you do first? 
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well-designed apps rock 


How am I supposed to know where to start? I 
feel like every time I get a new project to work 
on, everyones got a different opinion about what 
to do first. Sometimes I get it right, and sometimes I 
end up reworking the whole app because I started in the 
wrong place. I just want to write great software! 

So what should I do first in Rick*s app? 


O 


O 



How do you 
write great 
software. 


every 


time? 
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what does great software mean? 






GuitarSpec 


builder: Builder 
model: String 
type: Type 


topWood: Wood 


getBuilder(): Builder 
getModel(): String 
getType():Type 
getBackWood(): Wood 
getTopWoodQ: Wood 


■ guitars: Guitar [*] 


^ood 00 pv-ogvammcvs 
always lookih^ 
ways 仫 make -theiv- 
匕 o(ic mov-c -flexible. 


Wait a second... I hate 
to butt in, but what does ''great 
software" mean? Thafs sort of a 
vague term to be throwing around, 

isn’t it? 



Good question … and there are 
lots of different answers: 





I 




The custoiqer-friendly programmer says: 


“Great software always does what the customer 
wants it to. So even if customers think of new 
ways to use the software, it doesn’t 
break or give them unexpected results ■” 







The object-oriented programmer says: 


■ add6uitar(String, double, Builder, String, Type, 
Wood, Wood) 

IgetGuitar(String): Guitar 
I search(GuitarSpec): Guitar [*] 


“Great software is code that is object-oriented. 
So there’s not a bunch of duplicate code, and 
each object pretty much controls its own 
behavior. It’s also easy to extend because your 
design is really solid and flexible.” 



TW«s a??v-oa^ »s all 
about suve w 

Wat a?? docs. 


丁 his design—focused 
appvowh 

匕 ocUoir cx*fechsioh 

5hd ahd lakes 

desig, 

P^ttcirhs ahd pv-ovch 
士從 h—ues. 


TKe design-guru programmer says: 


|\fo 七 suve abou-t ^a*t all — 
七 — 咖？ I 七、 o^ r^w 
leavy, abou-t all -t^ese 如呼 
• m i\\t Aa?Ws. 


“Great software is when you use tried-and-true 
design patterns and principles. You’ve kept your 
objects loosely coupled, and your code open for 
extension but closed for modification. That also 
helps make the code more reusable, so you 
don’t have to rework everything to use parts of 
your application over and over again ■” 




a 




& 
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well-designed apps rock 



What do you think “great software” means? 

You’ve seen what several different types of programmers think 
great software is … so who is right? Or do you have your own 
definition of what makes an application great? It’s your turn to write 
down what you think makes for great software: 


\AMtc V ， 咖 c 4 山七 you thihk 

) so+twairc mcahs hcv-c. 、 
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great software satisfies the customer and the programmer 


ftrcat software is … 
more thaw just owe thiwg 

It’s going to take more than just a simple definition to 
figure out exactly what “great software” means. In fact, 
all of the different programmers on page 10 talked 
about a part of what makes software great. 

First, great software must satisfy 
the customer. The software must 
do what the customer wants it to do. 



Win your customers over 

Customers will think your software 
is great when it does what it’s 
supposed to do. 


Building software that works right is great, but what 
about when it’s time to add to your code, or reuse it 
in another application? It’s not enough to just have 
software that works like the customer wants it to; your 
software better be able to stand the test of time. 

Second, great software is 
well-designed, well-coded, and 
easy to maintain, reuse, and extend. 


Make your code as 
smart as you are. 

You (and your co-workers) will think 
your software is great when it’s easy 
to maintain, reuse, and extend. 
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well-designed apps rock 


昏 reat software iw 3 easy steps 



but 


1 Make sure your 
software does wkat tlie 
customer wants it to do. 


㈣ 口 

bas'»t ^ ° o 


sowC 

'youv 


-Vovc^cv 


^ - 


This step fosses Oh the 

Make sumc the app docs what it s 
supposed do FjggT. This is 
诎⑽ gcUihg 9^d7 c ^uivcm Ch ts 
ahd doihg some ar>alysis co^ts i h . 


2 . Apply bask 


00 


prmcip 


les to 



add flexibility. 


Out youv- so<f*Ua\re y/orks, you 
c, 3 y\ look (or 3r\y duplicate Code 
•t^a 七 mi#rb have slipped m, a^d 
make su\rc youVe us'm^ ^ood 00 
pv-oydmmrnj 七 etVmi'ues. 


与 ot a good objcd-t-o\richtcd 
a PP dots what it should? 
(仏 tir^c -to apply paUev-hs a^d 
fHhdipIcs -to make suv-c you 浐 
so-p*ty/5\rc is \rcady "fco use -fov- 
yca\rs -fco dome. 



3. Strive for a 
maintainable ， 
reusable design. 
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applying the steps 


Remember Rick? Remember his lost customers? 


Let’s put our ideas about how to write great software to the test and see if they hold 
up in the real world. Rick’s got a search tool that isn’t working, and it’s your job to 
fix the application, and turn it into something great. Let’s look back at the app and 
see what’s going on: 

rteves ouv 
•test fvo^vaw 
七七 v-cvcals 
a pvoklcw 
*bV^c 
scavA 


public class FindGuitarTester { 

public static void main(String[] args) 

// Set up Rick's guitar inventory 
Inventory inventory = new Inventory() 
initializeInventory(inventory); 


Ri^k s app should 
E\r'm ； s 

p\rc-Pc\rChdcs hcv-c- 

i 


fender' 


Guitar whatErinLikes = new Guitar (、、〃, 0, . 

''electric”，''Alder 

Guitar guitar = inventory.search(whatErinLikes); 
if (guitar != null) { 


''Stratocastor - 
''Alder"); 


*bWis 

m s 
•mvcwW/. 


FindGuitarTester.java 


inventory. addGuitar (''V95693", 

1499.95, ''Fender", ''Stratocastor 
''electric", ''Alder", ''Alder"); 


So let’s apply our 3 steps: 


r 


Rcwcwkcv-, >wc 
y\ccd *to s-tav-t ou*b 
V>Y wak •” suve 
a 代 adtually docs 
Y/V\a*b … 

av>d A 、 

no 七 dom^ 七 

V\^*t V'OY/. 


1 Make sure your 
software ctoes wkat tke 
customer wants it to cto. 


2. Apply basic 
00 principles to 
add IlexiLilitj. 




Dor/t woinry -too 啪 uA about 

^y ih 9 ^ apply paUcv-hs ov- 
o*thc\r 00 "tcdlihi^ucs -fco youv- app 
at this poihi.. just gc-t i-t -to 
心 ire it’s wovkihg like it should. 


3 . Strive lor a 
maintainable, 
reusable ctesigfn. 
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If were starting with functionality, 
let’s figure out whafs going on with 
that broken search() method. It looks like 
in Rick’s inventory, he’s got ''Fender 11 with a 
capital ' 、 F ,〃 and the customers specs have 
''fender" all lowercase. We just need to do a 
case-insensitive string comparison in the 
search() method. 


O 


Let’s 3 心 |j^| c 
Wp sor^c of ouv 
buddies. 



Frank: Sure, that would fix the problem Rick’s having now, but 
I think there’s probably a better way to make this work than just 
calling toLowerGaseO on a bunch of strings all over the place. 

Joe: Yeah, I was thinking the same thing. I mean, all that string 
comparison seems like a bad idea. Couldn’t we use constants or 
maybe some enumerated types for the builders and woods? 

Jill: You guys are thinking way too far ahead. Step 1 was 
supposed to be fixing the app so it does what the customer 
wants it to do. I thought we weren’t supposed to worry about 
design yet. 

Frank: Well, yeah, I get that we’re supposed to focus on the 
customer. But we can at least be smart about how we fix things, 
right? I mean, why create problems we’ll have to come back and 
fix later on if we can avoid them from the start? 





Jill ： Hmmm... I guess that does make sense. We don’t want our 
solution to this problem creating new design problems for us 
down the road. But we’re still not going to mess with the other 
parts of the application, right? 

Frank: Right. We can just remove all those strings, and the 
string comparisons, to avoid this whole case-matching thing. 

Joe: Exactly. If we go with enumerated types, we can ensure 
that only valid values for the builder, woods, and type of guitar 
are accepted. That’ll make sure that Rick’s clients actually get to 
look at guitars that match their preferences. 


Jill ： And we’ve actually done a little bit of design at the same 
time... very cool! Let’s put this into action. 


Don’t create 


problems to 
solve problems. 
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step 1: satisfy the customer 


Pitching String comparisons 

The first improvement we can make to Rick’s guitar search tool is getting 
rid of all those annoying String comparisons. And even though you could 
use a function like toLowerCase () to avoid problems with uppercase 
and lowercase letters, let’s avoid String comparisons altogether: 



-takes *tV\c 
plate o*f ov\t 
of 七 Vie jui-tav- 

^>v-o\>cv-tics 

i\\ai »s 

s*ta 灼 davd 

advoss 

all juitav-s. 


public enum Type { 

ACOUSTIC, ELECTRIC; 

public String toString() { 

switch(this) { 

r.a AHOITSTTH : rpf n rn ''a non .s~M n 〃： 

ca 


all Java ChurhS; 

typ cs ii)ai 

Uh ^'° h So ^ ^ like ^siay^is. 


de 


W C W 

as Wood^lT^ ： ^ 
j a \\ -tWc 


public enum Builder { 

FENDER, MARTIN, GIBSON, COLLINGS, 
OLSON, RYAN, PRS, ANY; 

public String toString() { 

switch(this) { 

case FENDER : return ''Fender 

case 


case 

case 






f hC bi 9 advah 〜s us — 

i possibl? 

y° u ^ppiy ^ a 

⑽ 呷阶伽 issues … 


public enum Wood { 

INDIAN—ROSEWOOD, BRAZILIAN—ROSEWOOD, MAHOGANY, 
MAPLE, COCOBOLO, CEDAR, ADIRONDACK, ALDER, SITKA; 


public String toString() { 

switch(this) { 

case INDIAN—ROSEWOOD: 

return ''Indian Rosewood ”； 
case BRAZILIAN—ROSEWOOD: 

return ''Brazilian Rosewood” 






D 


theve ar 

umb 


I Wood { I 
to- 1 

String()1 

iZJ 

Wood.java 


e no . 

Questions 


I’ve never seen an enum before. What is that, exactly? 


A! Enums are enumerated types. They’re available in C, C++, 
Java version 5.0 and up, and will even be a part of Perl 6. 


Enumerated types let you define a type name, like Wood, and then 
a set of values that are allowed for that type (like cocobolo, 
Sitka, and mahogany). Then, you refer to a specific value like 
this ： Wood.COCOBOLO. 




And why are enumerated types so helpful here? 
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public class FindGuitarTester { 

public static void main(String[] args) 

// Set up Rick's guitar inventory 
Inventory inventory = new Inventory() 
initializelnventory(inventory); 




The o 十 

IcR ^ov 
model ； s.mtc ， 
払 eve rcallv • 咖’七 
a \m\itA set ok 
•tKcsc l'»kc i^ert 
is y/rth bu»ldcvs 
dv\d N^ood- 




Guitar whatErinLikes = new Guitar (、、〃, 0, Builder. FENDER 
、 'Stratocastor 〃， Type.ELECTRIC, Wood.ALDER, Wood.ALDER) 

Guitar guitar = inventory.search(whatErinLikes); 
if (guitar != null) { 




FindGuitarTester.java 


H looks like 
^o-thihj has 
bu-t 

Chums ； we 

do^i have io 
wovry about 
"these domp^visohs 
jettihg screwed 
吁 by misspell— 
ov* tSsc issues. 


public Guitar search(Guitar searchGuitar) { 

for (Iterator i = guitars.iterator (); i.hasNext(); ) { 

Guitar guitar = (Guitar)i.next(); 

// Ignore serial number since that's unique 
// Ignore price since that A s unique 

if (searchGuitar.getBuilder() != guitar.getBuilder()) 

continue; _ 

String model = searchGuitar.qetModel() .^oLowerCase( Qr 
if ( (model ! = null) && (!model • equals (、'〃））&& 

(! model. equals (guitar. getModel () CtoLowerCase (1^1 )) 
continue; 

if (searchGuitar.getType() != guitar.getType()) 

continue; 

if (searchGuitar.getBackWood() != guitar.getBackWood( 

continue; 

if (searchGuitar.getTopWood() != guitar.getTopWood()) 

continue; 
return guitar; 

} 

return null; 


\\t OY\Vj 

: V>a 七 … c 灼 ccd 
y^ovv-Y 
jabou-t tast ov\ 
I is tiic wodcl， 
sm£.e s 

still a 




class 
Inver 
tory 

search ()] 


Inventory.java 


The cool thing about enums is that methods or classes that 
use them are protected from any values not defined in the enum. 

So you can’t misspell or mistype an enum without getting a compiler 
error. It’s a great way to get not only type safety, but value safety; you 
can avoid getting bad data for anything that has a standard range or 
set of legal values. 




I’m using an older version of Java. Am I stuck? 


No, not at all. Visit the Head First Labs web site at http ： // 
www. headfirstiabs . com, where we've posted a version of 
Rick’s Guitars that doesn’t use enums, and will work with older JDKs. 
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fragile apps break easily 


Let’s take a look at the big picture: 


mcpla^cd 
•^os£ o-f -those 
《七叫 piropcv-tics 
crvumcv-a'tcd 
types. 


"ow ^ add^iaM method 


\r 

TV\c scv-'ial nuwvbcv- 
is still u 灼 a 灼 d 

vjc Ic-ft model as a 
S'mdc tteve 
avc -thousands o( 
d\((crcY\i y«*tav- 
models out 七 hen. 

-too mdV^Y ^ or 3}n 
-to be V\elfful. 


Guitar 

serialNumber: String 
price: double 
builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 


addGuitar(String, double, Builder, String, Type, 
Wood, Wood) 
getGuitar(String): Guitar 
search(Guitar): Guitar 



v/ay 




TKc ^ui-tav class uses 七 V^csc 
enumerated -to rc^cse^i 

data、a ^ 从 3 七娜’七七 
strcy/cd U\> by tasc issues ov 

cvvovs 


^C\rc 3i\rc ou^ 
^^aied iyp es . 


£vcir\ *b^OU^ «*t 

looks like 七 Wnr^s 

Aa 呼 d … scavt^O, 
y\o^i >ncVc usnr»j 
C 灼 urns 七 o make suVC 
y/C do〆 七 miss 
mattKcs because 
o-f ov 

tafrtal ⑹七 10 灼 . 


So what have we really done here? 


We’ve gotten a lot closer to completing step 1 —~-v. 
in building great software. Rick’s problem with \ 
searches coming up empty when he’s got a matching 
guitar in his inventory is a thing of the past. 


Even better, we’ve made Rick’s application less 
fragile along the way. It’s not going to break so 
easily now, because we’ve added both type safety 
and value safety with these enums. That means less 
problems for Rick, and less maintenance for us. 



Code tlia-t is r>o-t -Pv-ajilc 
is JChCV-ally \TC*fc\r\rcd io 3s 
vobus-fc dode . 


1 Make sure your 
software ctoes wkat tke 
customer wants it to do. 
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well-designed apps rock 



Apply Step 1 to your own project. 


It’s time to see how you can satisfy your own customers. In the 
blank below, write a short description of the current project you’re 
working on (you can also use a project you finished recently): 


Now, write down the first thing you did when you started working on 
this project. Did it have anything to do with making sure your code 
did what the customer wanted it to? 


If you started out focusing on something other than the customer, 
think about how you might have approached things differently if 
you knew about the 3 steps to building great software. What would 
have been different? Do you think your application would be any 
better or worse than it is right now? 


D 


there ar 

umb 


e no , 

Questions 


So it’s OK to do a little design 
when I’m working on Step 1, right? 

A: Yeah, as long as your focus is 
still on the customer’s needs. You want 
the basic features of your application in 
place before you start making big design 
changes. But while you're working on 
functionality, you can certainly use good 
00 principles and techniques to make 
sure your application is well designed 
from the start. 




That diagram over on page 
18 is a class diagram right? Or is it 
class diagrams, since it’s more than 
one class? 

A! It is a class diagram, and a single 
diagram can have multiple classes in it. 

In fact, class diagrams can show a lot 
more detail than you’ve seen so far, and 
we’ll be adding to them in the next several 
chapters. 

So we’re ready to move on 
to Step 2, and start applying 00 
principles, right? 

Not quite... there’s one more 
thing Rick would like us to help him with 
before we’re ready to start analyzing 
our code for places we might be able to 
improve it. Remember, our first job is to 
please the customer, and then we really 
focus on improving our 00 design. 
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similar, but different 



So I thought this was 
perfect, but then I realized... 

I have two guitars that Erin would 
love. Could you make the search 
tool return both of them? 


〜 k“ appy 心 

^Hi， 99ui ^ hoi - 


^ would 

-to be 

冰 Ic to dhcdlc 
^ csc Sui-tdv-s. 


inventory. addGuitar (''V95693' 
1499.95 , Builder.FENDER, 
''Stratocastor”，Type • ELECTRIC 
Wood.ALDER, Wood.ALDER); 


TV^csc arc aUost 

saw. 0^ 

scv\al y\uwbcv a^d 
avc diWcvcY\-t- 


inventory. addGuitar (''V9512", 
1549.95, Builder.FENDER, 
''Stratocastor’、Type • ELECTRIC, 
Wood.ALDER, Wood.ALDER); 
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Rick's customers want choices! 


Rick’s come up with a new requirement for his app: he wants his 
search tool to return all the guitars that match his client’s specs, not 
just the first one in his inventory. 



addGuitar(String, double, Builder, String, Type, 
Wood, Wood) 
getGuitar(String): Guitar 
search(Guitar): List 


% io b c a bl c 

’ multiple “ 

i-P R- lt k -th^ 

7 ^ his 

dieivfc s speds. 


V Cocte Magnets 



Let’s continue with Step 1, and make sure we’ve got the app working right. Below 
is the code for the search() method in Rick’s inventory tool, but it’s up to you to fill 
in the missing pieces. Use the code magnets at the bottom of the page to return 
all the matching guitars from Rick’s inventory. 


public _ search(Guitar searchGuitar) { 

_ _ = new _(); 

for (Iterator i = guitars.iterator(); i.hasNext(); ) { 

Guitar guitar = (Guitar)i.next(); 

// Ignore serial number since that A s unique 

// Ignore price since that f s unique 

if (searchGuitar.getBuilder() != guitar.getBuilder()) 

continue; 

String model = searchGuitar.getModel(); 

if ( (model ! = null) && (!model • equals (、'〃））&& 

(!model.equals(guitar.getModel()))) 
continue; 

if (searchGuitar.getType() != guitar.getType()) 

continue; 

if (searchGuitar.getBackWood() != guitar.getBackWood()) 

continue; 

if (searchGuitar.getTopWood() != guitar.getTopWood()) 

continue; 


return 

















































































maintenance, design, and requirements 


Cocte Magnets 



Let’s keep on with Step 1, and make sure we’ve got the app working right. Below is 
the code for the search() method in Rick’s inventory tool, but it’s up to you to fill in 
the missing pieces. Use the code magnets at the bottom of the page to return all 
the matching guitars from Rick’s inventory. 


public 


List 


earch (Guitar sea 士 eh-&i-i 士 fea-p 


for (工 


matchingGuitars 


new I LinkedList ■ 


•ars . iterator () 


lhasNext () 


(Guitar)i.next(); 

that A s unique 


// Ignore serial number since 
// Ignore price since that f s unique 

if (searchGuitar.getBuilder() != guitar.getBuilder()) 

continue; 


You ad-tually toM 
V^ave used c'i*tV\cv- a 
L'mkcdLis-t oy 
Av-vaYt-is*t We … 
bo*tV\ t\\o\tts av-c 0^- 


String model = searchGuitar.getModel(); 
if ( (model ! = null) && (!model • equals (、'〃））&& 

(!model.equals(guitar.getModel()))) 
continue; 


if (searchGuitar.getType() != guitar.getType()) 

Ala-bihihj jui-tav-s continue; 

jc-t added-to-the if (searchGuitar.getBackWood() != guitar.getBackWood() 

lis-fe o( op-tiorvs continue; 

;Ridks dlierrfe. if (searchGuitar.getTopWood() != guitar.getTopWood()) 



guitar 



Le*f*tovev" ma^cb- 



e no . 

Questions 




So I’m not done with the first 


step until the application works like my 
customer wants it to? 


A! Exactly. You want to make sure that 
the application works like it should before 
you dive into applying design patterns or 
trying to do any real restructuring of how the 
application is put together. 


And why is it so important to 
finish Step 1 before going on to Step 2? 


You seem sort of hung up on this 
“Step 1” and “Step 2” business. What if I 
don’t code my apps that way? 


A! You’re going to make lots of 
changes to your software when you’re 
getting it to work right. Trying to do too much 
design before you’ve at least got the basic 
functionality down can end up being a waste, 
because a lot of the design will change as 
you’re adding new pieces of functionality to 
your classes and methods. 


There’s nothing that says you have 
to follow these steps exactly, but they do 
provide an easy path to follow to make 
sure your software does what it’s supposed 
to, and is well-designed and easy to 
reuse. If you’ve got something similar that 
accomplishes the same goals, that’s great! 
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well-designed apps rock 


Test drive 

We’ve talked a lot about getting the right requirements from the 
customer, but now we need to make sure we’ve actually got those 
requirements handled by our code. Let’s test things out, and see if our 
app is working like Rick wants it to: 


Wccts 

七 he 七 es 七 

updated 
{p use 七 he 
灼 vcvsioir» 
o^c R.ifiVs 
scav'tii *tool 


TWis Wc 
v/c a 
y/Viole 

七 hal 
七 V\c s 

S\>c6s. 


public class FindGuitarTester { 

public static void main(String[] args) 

// Set up Rick^ s guitar inventory 
Inventory inventory = new 工 nventory() 
initializelnventory(inventory); 




Guitar whatErinLikes = new Guitar ('' 〃， 0, Builder • FENDER, 

''Stratocastor〃, Type . ELECTRIC, 
Wood.ALDER, Wood.ALDER); 

List matchingGuitars = inventory.search(whatErinLikes); 

if (!matchingGuitars.isEmpty()) { 

System, out. print In (''Erin, you might like these guitars :’’）； 

for (Iterator i = matchingGuitars.iterator(); i.hasNext();) 

Guitar guitar = (Guitar)i.next(); 

System. out. print In (We have a '、+ 

guitar . getBuilder () +''、' + guitar . getModel () +''、' + 
guitar . getType () + 、、 guitar : \n '' + 
guitar . getBackWood () + '、 back and sides, \n '' + 
guitar. getTopWood () + '' top. \n You can have it for only 


this hew 
vcv-sioh, wc t\tcd 
io itcira-tc OVCV- 

^1! "tKc dKoines 

代 tuacd -fv-om 

■feKc sca^K -tool. 


guitar . getPrice () + 、'! \n - ,r ); 

} 

else { 

System, out. print In (''Sorry, Erin, we have nothing for you . f, ); 



class 
FindGui- 
tar { 
main ()1 


FindGuitarTester.java 


c 


File Edit Window Help SweetSmell 


% java FindGuitarTester 

Erin, you might like these guitars : 

We have a Fender Stratocastor electric guitar 
Alder back and sides, 

Alder top. 

You can have it for only $1499.95! 

We have a Fender Stratocastor electric guitar 
Alder back and sides, 

Alder top. 

You can have it for only $1549.95! 


£vcv*Y*b^n^5&r … yts 

sevev*dl juitav* vcd.ommcir>dat«o^s ; 

Risk's tusWcv-s avc ―吒 
-to s*tav 七 buY'mj ju'i*tav*s ay’irv. 



Yes! Thafs exactly what I 
want it to do. 
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apply your oo principles 


Pack to our steps 

Now that Rick’s all set with our software, we can begin to use some 
OO principles and make sure the app is flexible and well-designed. 




sure your 
software does wkat tke 
customer wants it to do. 


% Apply basic 

00 principles to 
add flexibility. 


Koy/ tta-t ttc a\>\> does Wat 
R-,dk >wcVc ^'rn'isKcd uf 

W\i\\ 七 Wis 


t 


3 . Strive lor 
maintainable, 
reusable ctesign 


So this is where we can 
make sure there's no duplicate 
code, and all our objects are well 
designed, right? 


HevVs you 
s<^P*t>wav-c ttat >wo\rks, a^d 
make sure tte I 七 s ? u 七 

actually ^akcs sense ， 
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Looking for problems 

Let’s dig a little deeper into our search tool, and see if we can find any 
problems that some simple OO principles might help improve. Let’s start by 
taking a closer look at how the search () method in Inventory works: 



looking for a Martin 
acoustic guitar... you got 
anything, Rick? 







The dieirt provides a set of spds 
-fov- ihciv ideal gui-ta^ m the 
-fovm o-f a ^ui*ta\r objedt. 





The dicht docs^-t 
provide a phde 

sc 以 I humbcir, sihde 
"those av'c unique io 

cadh P 扣 tidu ‘ ^uiiar. 

She just provides 
s P cds io Oh. 


null A nulT^) 
Builder.MARTIN 
Type.ACOUSTIC 
M OM-18 M 
Wood.MAHOGANY 
Wood.ADIRONDACK J 

Guitar 





Is anything wrong here? What 
problems might there be with 
Rick’s search tool? 


乙 ppo uidds dujLfp^uY 'uoj ； oun; 
s；j o; ;eLi; djeduioo pue ‘pduwu s! 
;oefqo qoee inoqe >ju!Li 丄 : 叫 ! h 



TKc sear 吐 0 method »s 
tailed Witt 七 sfets 
ttc av^d be—s a 

scav-dK Risk's 'mvc^tov-y- 


^t\\ ^uitav m 
mven-bovy 

•IS 6 om\>av-cd 

d^dms4 ttc s^tts 
•m i\\t 

^uitav- object- 



TV^cvc s a ^uitav objc6*t (or cadK 
y,-tar rn KitV!s mvc^y, sW«^a 
七 he scv-'ial v^umbev-, ^>v-'» 6 c, 

S^tts (or tat\\ ms*br_ ⑶七， 
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analysis of the searchf) method 

Analyze the search!) method 

Let’s spend a little time analyzing exactly what goes on in the 
search () method of Inventory. java. Before we look at 
the code, though, let’s think about what this method should do. 



The client provides their guitar preferences. ^ — 

Each of Rick’s clients has some properties that they’re interested 
in finding in their ideal guitar: the woods used, or the type of 
guitar, or a particular builder or model. They provide these 
preferences to Rick, who feeds them into his inventory search tool. 


TV^c o^ly 

y^eval w^tics d av^ 

a senal v^umbev ov- a 


o The search tool looks through Rick’s inventory. 


Once the search tool knows what Rick’s client wants, it starts to 
loop through each guitar in Rick’s inventory. 


o 



Each guitar is compared to the client’s preferences. 


For each guitar in Rick’s inventory, the search tool sees if that 
guitar matches the client’s preferences. If there’s a match, the 
matching guitar is added to the list of choices for the client. 



All the gchcval 

l»kc "the -top Wooc | 3hd gui-bv 

builder Co^td io the 

亡 lieivt's pvc-fcirchdcs. 


Rick’s client is given a list of matching guitars. 


Finally, the list of matching guitars is returned to Rick and his 
client. The client can make a choice, and Rick can make a sale. 


Use a textual description ol tke problem 
you’re trying to solve to make sure tkat 
your ctesign lines up witk tke intenctect 
functionality o{ your application. 
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The Mystery 

of the 

Mismatched 
Object 
Type 


In the better-designed areas of Objectville, objects 
are very particular about their jobs. Each object is 
interested in doing its job, and only its job, to the best 
of its ability. There’s nothing a well-designed object 
hates more than being used to do something that really 
isn’t its true purpose. 

Unfortunately, it’s come to our attention that this is 
exactly what is happening in Rick’s inventory search 
tool: somewhere, an object is being used to do 
something that it really shouldn’t be doing. It’s your job 
to solve this mystery and figure out how we can get 
Rick’s application back in line. 





STOP 

_ 


a 灼 d solve 


To help you figure out what’s gone amiss, here are 
some helpful tips to start you on your search for the 
mismatched object type: 

1. Objects should do what their names indicate. 

If an object is named Jet, it should probably takeOff() 
and land(), but it shouldn’t takeTicket() — that’s the job 
of another object, and doesn’t belong in Jet. 

2. Each object should represent a single concept. 

You don’t want objects serving double or triple duty. 
Avoid a Duck object that represents a real quacking 
duck, a yellow plastic duck, and someone dropping 
their head down to avoid getting hit by a baseball. 

3. Unused properties are a dead giveaway. 

If you’ve got an object that is being used with no-value 
or null properties often, you’ve probably got an object 
doing more than one job. If you rarely have values for a 
certain property, why is that property part of the object? 
Would there be a better object to use with just a subset 
of those properties? 


What do you think the mismatched object type is? Write your answer in the blank below: 


What do you think you should do to fix the problem? What changes would you make? 
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duplicate code sucks 



Encapsulation 
allows you to 
tide tke inner 


You know, Rick’s clients really 
aren't providing a Guitar object... 
I mean, they don’t actually give him 
a guitar to compare against his 
inventory. 


Frank: Hey, that’s right, Joe. I hadn’t thought about that before. 

Jill ： So what? Using a Guitar object makes it really easy to do 
comparisons in the searchf) method. 

Joe: Not any more than some other object would. Look: 



A small 





•method ih 
(i^vch-fcov-y. 


Joe: It really doesn’t matter what type of object we’re using there, as 
long as we can figure out what specific things Rick’s clients are looking 
for. 


Frank: Yeah, I think we should have a new object that stores just the 
specs that clients want to send to the searchf) method. Then they’re not 
sending an entire Guitar object, which never seemed to make much 
sense to me. 


workings ol your 
application’s 
parts，tut yet 
make it clear 
wkat eack part 
does. 



aV,ead 11 ；.^ 
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Jill: But isn’t that going to create some duplicate code? If there’s an 
object for all the client’s specs, and then the Guitar has all its properties, 
we’ve got two getBuilderf) methods, two getBackWoodf) methods... 
that’s not good. 

Frank: So why don’t we just encapsulate those properties away from 
Guitar into a new object? 

Joe: Whoa... I was with you until you said “encapsulate.” I thought 
that was when you made all your variables private, so nobody could use 
them incorrectly. What’s that got to do with a guitar’s properties? 

Frank: Encapsulation is also about breaking your app into logical 
parts, and then keeping those parts separate. So just like you keep the 
data in your classes separate from the rest of your app’s behavior, we 
can keep the generic properties of a guitar separate from the actual 
Guitar object itself. 

Jill: And then Guitar just has a variable pointing to a new object type 
that stores all its properties? 


Frank: Exactly! So we’ve really encapsulated the guitar properties out 
of Guitar, and put them in their own separate object. Look, we could 
do something like this... 




well-designed apps rock 


iflrpsn your psncil Create the GuitarSpec object. 

、 Below, you’ll see the class diagram for Guitar, and the new GuitarSpec object that Frank, Jill, and 
Joe have been discussing. It’s your job to add all the properties and methods that you think you’ll 
need to GuitarSpec. Then, cross out anything you don’t need anymore in the Guitar class. Finally, 
we’ve left you some space in the Guitar class diagram in case you think you need to add any new 
properties or methods. Good luck! 


serialNumber: String 
price: double 
builder: Builder 
model: String 
type: Type 
backWood: Wood 
top Wood: Wood 



getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 


^ |-f you s 七 u 火 about 七 iVmy 七 ha 七 

Con\n\ov\ ^u'rtav- objcti v/h 七 3 

dJicyvt v/ould su^ly "to method- 
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encapsulate what varies 


il^harpen your pencil 

answers 


Create the GuitarSpec object. 

Below you’ll see the class diagram for Guitar, and the new GuitarSpec object 
that Frank, Jill, and Joe have been discussing. It’s your job to add all the 
properties and methods that you think you’ll need to GuitarSpec. See if you 
made the same changes that we did. 


"two p\ropc\rfeics avc 
still uhi^uc io eadh 
so tKcy s-feay. 



TV^csc avc tV^c 

^VO^CV*t»CS 

減 R'«^s 

t\\t^ —7 一 
■to scavtV^O, so 

wOVC 

We also heed a 
V-C-fc\rChdC {p 
a ^ui-tavSpcd 
object -fo\r 
cadli jui-tav. 


c 


serialNumber: String 
price: double 
builder: Buildef 

model: String- 

■iype: Typ e- 

backWood: 
■topWood: Wood 

spec: fruitarSpec 


TKc methods -folloy/ {Mt same yB 
as i\\t pvo^cvtics ： >NC verwove a^Y 
duplication between dien 七 s s^>Cd. 

and 七 he ^ui-tav object. 



getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
■^otB^dorQ; Builder 

■§otModol(): String 

g^tTypeO ： Type 


I/Vc ； vc vemoved 
duplicated 
todt by moving 
dll "tliC dommon 
flropcirtics- 

3hd v-da*tcd 
methods - iivto 
an objed 七 
v/c dan use -fov 
bo-tli scav-^K 
v-c<\ucs*b and 
gui*tav derails. 


Now update your own code 

With this class diagram, you should be able to add the 
GuitarSpec class to your application, and update the Guitar 
class as well. Go ahead and make any changes you need to 
Inventory. java so that the search tool compiles, as well. 
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e no 


there ar _ . 

Dumb Questions 


I understand why we need an object for the client 
to send specs to search() … but why are we using that 
object to hold properties for Guitar, too? 

Suppose you just used Guitar Spec to hold client 
specs for sending to the search () method, and you kept 
the Guitar class just the same as it was. If Rick started 
carrying 12-string guitars, and wanted a numStrings 
property, you’d have to add that property—and code for a 
getNumStrings () method 一 to both the Guitar Spec 
and Guitar classes. Can you see how this would lead to 
duplicate code? 

Instead, we can put all that (potentially) duplicate code into 
the Guitar Spec class, and then have Guitar objects 
reference an instance of it to avoid any duplication. 

Anytime you see 
duplicate cocfe, look for a 
place to encapsulate! 

I still am confused about how this is a form of 
encapsulation. Can you explain that again? 

The idea behind encapsulation is to protect information 
in one part of your application from the other parts of your 
application. In its simplest form, you can protect the data 
in your class from the rest of your app by making that data 
private. But sometimes the information might be an entire 
set of properties—like the details about a guitar—or even 
behavior—like how a particular type of duck flies. 

When you break that behavior out from a class, you can 
change the behavior without the class having to change as 
well. So if you changed how properties were stored, you 
wouldn’t have to change your Guitar class at all, because 
the properties are encapsulated away from Guitar. 

That’s the power of encapsulation: by breaking up the different 
parts of your app, you can change one part without having to 
change all the other parts. In general, you should encapsulate 
the parts of your app that might vary away from the parts that 
will stay the same. 


Let s see Ko>w v/cVc tommj 3lo^j oy\ 
ouv tWcc sit^s to yr^i so^tv/avc. 


sure your 
software does 
wkat tke customer 
wants it to do. 


N^a 七 wcVc dornj 
y\o^i ： on design. 



2. Apply nasiic 
00 principles to 
add flexibility. 


5 

丁 his is y/Kc\rc 
you look -Po\r bi^ 
fv-oblcms, cspcdially 
related {o -tilings 
like duplicate todt 
ov* bad dass desi^h. 


尸 


3. Strive lor 
maintainatle, 
reusable design. 


RcmCmbcV, JO*t CVCh 

move design >wovk "to do ih "tiiis 
step, so bc-fovc youVc doiac, 
youv so^*tv/3V"C is vcdlly c3sy -to 

CX.*tcir\di airtd VCUSC. 
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updating the inventory 

Update the Iwvcwtory class 

Now that we’ve encapsulated away the specifications of a guitar, 
we’ll need to make a few other changes to our code. 


r 


Inventory 

guitars: List 

addGuitar(String, double, Builder, String, Type, 
Wood, Wood) 
getGuitar(String): Guitar 
search(GuitarSpec): List 


ms 七 ead a 灼 

^u'rtav- object 


public class Inventory 



^ use m tof M 


This 亡 ode is almost -the 
same as i-fc was bc-fovc ； 
c^cp-t h0 w wcVc usihj 
^-foirrha-tioh ih -the 
^ui-ta\r£pc^ objedt 


public List search (GuitarSpec searchSpec) { 

List matchingGuitars = new LinkedList(); 
for (Iterator i = guitars.iterator (); i.hasNext() 
Guitar guitar = (Guitar)i.next (); 


GuitarSpec guitarSpec = guitar.getSpec() 


if (searchSpec .getBuilder() != guitarSpec .getBuilder()) 

continue; 

String model = searchSpec .getModel().toLowerCase(); 
if ( (model ! = null) && (!model • equals ('、〃））&& 

(!model.equals (guitarSpec .getModel().toLowerCase()))) 
continue; 

if ( searchSpec .getType( ) != guitarSpec .getType()) 

continue; 


if ( searchSpec .getBackWood() 
continue; 

if ( searchSpec .getTopWood() 
continue; 
matchingGuitars.add(guitar); 

} 

return matchingGuitars; 


=guitarSpec .getBackWood() 
guitarSpec .getTopWood()) 



tUs S_S. 


Inventory.java 
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ftettiwg ready for another 
test drive 

You’ll need to update the FindGui tarTes ter 
class to test out all these new changes: 


public class FindGuitarTester { 


public static void main(String[] args) { 

// Set up Rick/ s guitar inventory 
TW»s Wc, Inventory inventory = new Inventory(); 

se 灼 ds a initializelnventory (inventory); 

-to 

scavtV^O- - > Guitar Spec whatErinLikes — 

new GuitarSpec (Builder • FENDER, ''Stratocastor”，Type • ELECTRIC, 

Wood.ALDER, Wood.ALDER); 


List matchingGuitars = inventory.search(whatErinLikes); 
if (!matchingGuitars.isEmpty()) { 

System, out .printIn (''Erin, you might like these guitars :〃） ； 
for (Iterator i = matchingGuitars.iterator(); i.hasNext(); ) { 

Guitar guitar = (Guitar)i.next(); 

Guitar Spec spec = guitar .getSpec () ; ^ —_ __^ 

System. out. print In ('' We have a " + WcVc usmj ttc 

spec . getBuilder () + '、" + spec . getModel () +'、’’+ tlass 

spec.getType () + '' guitar: \n " + as >wcll. 

spec . getBackWood () + '' back and sides, \n " + 

spec. getTopWood () + '' top. \n You can have it for only $" + 


guitar.getPrice() 




! \n 






else { 

System, out .printIn (''Sorry, Erin 


we have nothing for you; 


private static void initializelnventory(Inventory inventory) 
// Add guitars to the inventory... 

} 



纤 ONLINE 


You can download the current version of Rick’s search tool at 
http://www.headfirstlabs.com. Just look for Head First OOA&D, 
and find “Rick’s Guitars (with encapsulation)’’. 



FindGuitarTester.java 
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using object-oriented principles 


+ WMV i 



You’ve learned a lot about writing great software, and there’s still more to 
go! Take a deep breath and think about some of the terms and principles 
we’ve covered. Connect the words on the left to the purposes of those 
techniques and principles on the right. 


f ⑽刪切 

Encai>SsiLatipH 

fsiHCtlPHailty 


Without me, youll neVer actually make the 
customer tappy. Nq matter how well-designed your 
application is, i 7 m the thing that puts a smile on 
the customers face. 

I’m all about reuse and making sure youve not 
trying tQ solve a problem that someone else Las 
already figured out 

Yon use me tQ keep the parts of your coje that 
stay the same separate from the parts iMt change ； 
then its really easy tQ make changes tQ your code 
Without breaking everything. 

Use me so thsttyour software can change and grow 
without constant rework. 1 keep your application 

\ -n l^v /-\ t rv l -n O rVi /-\ 


► Answers on page 52 . 



e no . 

Questions 


Encapsulation isn’t the only 00 principle I can use at 
this stage, is it? 


But I don’t really see how this encapsulation makes my 
code more flexible. Can you explain that again? 


Nope. Other good 00 principles that you might want to think 
about at this stage are inheritance and polymorphism. Both of these 
relate to duplicate code and encapsulation though, so starting out by 
looking for places where you could use encapsulation to better your 
design is always a good idea. 

We’ll talk about a lot more 00 programming principles throughout this 
book (and even see a few sing in Chapter 8), so don’t worry if you 
are still getting a handle on things at this point. You’ll learn a lot more 
about encapsulation, class design, and more before we’re done. 


A〕Once you’ve gotten your software to work like it’s supposed 
to, flexibility becomes a big deal. What if the customer wants to 
add new properties or features to the app? If you’ve got tons of 
duplicate code or confusing inheritance structures in your app, 
making changes is going to be a pain. 

By introducing principles like encapsulation and good class design 
into your code, it's easier to make these changes, and your 
application becomes a lot more flexible. 
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fretting back to Rick's app … 

Let’s make sure all our changes haven’t messed up the 
way Rick’s tool works. Compile your classes, and run the 

FindGuitarTes ter program again: 


丁 vcsul 七 s 3vc^ *b 
tV>'»s t'wc, 

Ut tKc «s 

bcttcv- desired, 
wov-c {icWWc. 



File Edit Window Help NotQuiteTheSame 


% java FindGuitarTester 

Erin, you might like these guitars : 

We have a Fender Stratocastor electric guitar: 
Alder back and sides, 

Alder top. 

You can have it for only $1499.95! 

We have a Fender Stratocastor electric guitar: 
Alder back and sides, 

Alder top. 

You can have it for only $1549.95! 



Can you think of three specific ways that well- 
designed software is easier to change than software 
that has duplicate code? 
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time for some serious design 

Pesign design twice 

Once you’ve taken a first pass over your software and applied 
some basic OO principles, you’re ready to take another look, 
and this time make sure your software is not only flexible, but 
easily reused and extended. 


Make sure your 
software ctoes 
wkat tke customer 
wants it to cto. 


▼ 


Apply basic 


It's time to really think about 
reuse, and how easy it is to make 
changes to your software. Here's where 
you can take some well-designed classes 
and really turn them into a reusable, 
extensible piece of software. 


O 


00 principles to 
add flexibility• 


t 


3 . Strive for a 

maintainable, 
reusable design. 


V ou；vc ^Plicd 
1 ° 卜呻 ― u 

» _ paiW . 
以 , Oh ^cusc. 
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well-designed apps rock 


Ireallyl 

Let's make sure Iwvcwtory.java ^well-designed 


We’ve already used encapsulation to improve the design of Rick’s 
search tool, but there are still some places in our code where we 
could get rid of potential problems. This will make our code easier 

to extend when Rick comes up with that next new feature he wants ^_^ 

in his inventory search tool, and easier to reuse if we want to take 
just a few parts of the app and use them in other contexts. 


/^ow that you vc ^adc R\tk a wo^ki^ 
tool, you bjow hc ； s 9 o^a taw you badk 
hc made h> the iool 


Hcvcs -tV^C 

|yw ⑼ W/j ava . 

Take a t\o^t 

look 3 *b 
todt- 


public List search(GuitarSpec searchSpec) { 

List matchingGuitars = new LinkedList(); 

for (Iterator i = guitars.iterator(); i.hasNext(); ) { 

Guitar guitar = (Guitar)i.next(); 

GuitarSpec guitarSpec = guitar.getSpec(); 

if (searchSpec.getBuilder() != guitarSpec.getBuilder()) 

continue; 

String model = searchSpec.getModel().toLowerCase(); 

if ( (model ! = null) && (! model. equals ('、〃））&& 

(!model.equals(guitarSpec.getModel().toLowerCase())) 
continue; 

if (searchSpec.getType() != guitarSpec.getType()) 

continue; 

if (searchSpec.getBackWood() != guitarSpec.getBackWood() 

continue; 

if (searchSpec.getTopWood() != guitarSpec.getTopWood()) 

continue; 

matchingGuitars.add(guitar); 


return matchingGuitars; 


Inventory.java 



XXXXXXXXXXXXXXXXXKXXXXXXXXXXXXXXXKXXXXXXXXXXXXXXXXXXXXKXXXXXXOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO 

What would you change about this code? 

There’s a big problem with the code shown above, and it’s up to you to figure it out. In 
the blanks below, write down what you think the problem is, and how you would fix it. 









xn 
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are simple changes simple? 


You know, Ive always loved 
playing 12-string guitars. How hard 
would it be to update my app so I 
can sell 12-string guitars, and let my 
clients search for them, too? 




How easy is it to make this 
change to Rick’s application? 

Take a look at the class diagram for Rick’s 
application, and think about what you 
would need to do to add support for 
12-string guitars. What properties and 
methods would you need to add, and to 
what classes? And what code would you 
need to change to allow Rick’s clients to 
search for 12-strings? 

How many classes did you have to modify 
to make this change? Do you think Rick’s 
application is well designed right now? 


Guitar 

serialNumber: String 
price: double 
spec: GuitarSpec 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpecQ ： GuitarSpec 
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GuitarSpec 

builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 


Annotate Rick’s class diagram. 

Rick wants to be able to sell 12-string 
guitars. Get out your pencil, and add notes 
to the class diagram showing the following things: 

1 ■ Where you’d add a new property, called numStrings, to store the 
number of strings a guitar has. 

2. Where you’d add a new method, called getNumStrings(), to return 
the number of strings a guitar has. 

3. What other code you think you’d need to change so that Rick’s 
clients can specify that they want to try out 12-string guitars. 

Finally, in the blanks below, write down any problems with this design 
that you found when adding support for 12-string guitars. 


harpen your pencil 



Inventory 

guitars: List 

addGuitar(String, double, Builder, String, Type, 
Wood, Wood) 
getGuitar(String): Guitar 
search(GuitarSpec): List 



s d Kih-t-* you should 

ah 扣 sw 饮 Kc\rc y-elaied io 

wKat you w\ro-tc dowh ih iKe 
blanks badk ov\ page 1>1. 




What’s the advantage of using a 
numStrings property instead of 
just adding a boolean property to 
indicate if a guitar is a 12-string? 
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we have an encapsulation problem 


t^harpen your pencil 

answers 


Annotate Rick’s class diagram. 

Rick wants to be able to sell 12-string guitars. Get out your pencil, 
and add notes to the class diagram showing the following things: 


1 ■ Where you’d add a new property, called numStrings, to store the number of strings a 
guitar has. 

2. Where you’d add a new method, called getNumStrings(), to return the number of strings 
a guitar has. 

3. What other code you think you’d need to change so that Rick’s clients can specify that 
they want to try out 12-string guitars. 


Finally, in the blanks below, write down any problems with this design that you found when 
adding support for 12-string guitars. 


WcYe adding a property to fruitarSpec, but we 
have to change code m the Inventory class's 

search!) method, as well as m the constructor 

to the fruitar class. 



1+evVs v/Kai wc up 

with... did you y/vitc dovm 
somrtliihj similav? 


y>ccd -fco sdd a 

tlass. 



Wc rittA 3 
^ctN uwS*br” s () 
wctV'od 
dlass -to 代 

a ^u'»"t3v- V^as- 


GuitarSpec 

builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 


Guitar 

serialNumber: String 
price: double 
spec: GuitarSpec 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec ()： GuitarSpec 


° + this tlass, sihde 
it takes ih all 
仏 C p\ropc\rfeics irt 
^ui-fea\r£pcd, av\d 

objed-fe i-fescl-p. 


This dlasss add^ui-tav-0 ^ti\\od 
deals y/i*tV\ all <^f a jui-tav- s 
^>v-o\>cv-tics, -too- \>v-o\>cv-*tics 
medv^s dV\a^cs -to tWis method- 

ttaVs a Yro\)\tn^p 


Inventory 


7 


guitars: List 

addGuitar(String, double, Builder, String, Type, 
Wood, Wood) 
getGuitar(String): Guitar 
search(GuitarSpec): List 



■"Awfehc\r pv-oblcm ： 
wc have -to 
dhahjc -fehc 
s ca\rdKO method 

^circ io SUotAYii 

for the hew 
f^ropcirfey *, h 

^ui-feav-£pcfi. 
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So thafs the problem, 
right? We shouldiVt have to 
change code in Guitar and Inventory to 
add a new property to the GuitarSpec 
class. Can't we just use more 
encapsulation to fix this? 


That’s right — we need to 
encapsulate the guitar 
specifications and isolate 
them from the rest of Rick’s 
guitar search tool. 

Even though you’re adding a property 
only to the Guitar Spec class, there 
are two other classes that have to be 
modified: Guitar and Inventory. 

The constructor of Guitar has to take 
an additional property now, and the 
search () method of Inventory has to 
do an extra property comparison. 

"This dohstvufi'toir dlrcS'tcs B 
^ui-tairSpcd objcdi so evevy 
-the dhahjes, -this 

^odc Has -to 亡 "too. 



TWis todt is easy 
reuse, T\\t dasscs avc all 
•m 七 ⑶ de 此 and Y ou 
t use one dbss Vrbhou 七 
us'm^ dll o*bV>cv-s, *too- 


publio 


ic^uita^^ 


tring serialNumber, 


Builder builder. 

String model. Type type, 

J^ackWood, Wood topWood) J{ 
this . serialNumber = seriali\lumb^l ； 
this.price = price, 

this . spec = ^iew GuitarSpe5"(ibuTlder, model, 

topWood); 


— \JL 丄 ; — 

^ew GuitarSpec^rtbi^lder, 
fType,""^ackWood, t 


Guitar.java 


puitarSpec searchSpec) { 

List matchingGuitars = new LinkedList(); 
for (Iterator i = guitars.iterator (); i.hasNext(); ) { 

Guitar guitar = (Guitar)i.next(); 

GuitarSpec guitarSpec = guitar.getSpec (); 
if (searchSpec.getBuilder() != guitarSpec.getBuilder()) 

continue; 

String model = searchSpec.getModel().toLowerCase(); 
if ( (model ! = null) && (!model • equals (''〃））&& 

(!model.equals(guitarSpec.getModel() .toLowerCase ()))) 
continue; 

if (searchSpec.getType() != guitarSpec.getType()) 

continue; 


if (searchSpec.getBackWood() 
continue; 

if (searchSpec.getTopWood() 
continue; 

matchingGuitars.add(guitar); 

} 

return matchingGuitars ; 


=guitarSpec.getBackWood()) 
guitarSpec.getTopWood()) 


Inven¬ 
tory { 

search() I 


Inventory.java 
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strive for reusable applications 



Design Puzzle 


It’s not enough to know what’s wrong with Rick’s app, or even to figure out that 
we need some more encapsulation. Now^^need to actually figure out how to fix 
his app so it’s easier to reuse and extend. Y 


The problem: 

Adding a new property to Guitar Spec. java results in changes 
to the code in Guitar. java and Inventory. java. The 

application should be restructured so that adding properties to 
Guitar Spec doesn’t affect the code in the rest of the application. 


Your task: 


j\\\ \jO\A Should 

V^avc "to 


\jo\jx 6odc 

dvcatcs a sa^lc 
今 … "tav 


6ov\S-tvud-^ 


❶ Add a numStrings property and getNumStrings () method to 
Guitar Spec. java. 

❾ Modify Guitar. java so that the properties of Guitar Spec are 
encapsulated away from the constructor of the class. 

Change the search () method in Inventory. java to delegate 
comparing the two Guitar Spec objects to the Guitar Spec class, 
instead of handling the comparison directly. 

o Update FindGuitarTester. java to work with your new classes, and 
make sure everything still works. 

❺ Compare your answers with ours on page 44, and then get ready for 
another test drive to see if we’ve finally got this application finished. 


sure what 
dclcja-tioh is? 

Chcdk "this 
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e no . 

Questions 


You said I should “delegate” 
comparisons to GuitarSpec. What’s delegation? 


And what does delegation have to do 
with code being more reusable? 


A! Delegation is when an object needs to 
perform a certain task, and instead of doing that 
task directly, it asks another object to handle the 
task (or sometimes just a part of the task). 

So in the design puzzle, you want the search () 
method in Inventory to ask GuitarSpec to 
tell it if two specs are equal, instead of comparing 
the two GuitarSpec objects directly within the 
search () method itself, search () delegates 
the comparison to GuitarSpec. 


A! Delegation lets each object worry about 
equality (or some other task) on its own. This 
means your objects are more independent of each 


other, or more loosely coupled. Loosely coupled 
objects can be taken from one app and easily 
reused in another, because they’re not tightly tied 
to other objects’ code. 


again? 


And what does loosely coupled mean 


What’s the point of that? 

A! Delegation makes your code more 
reusable. It also lets each object worry about 
its own functionality, rather than spreading the 
code that handles a single object’s behavior all 
throughout your application 

One of the most common examples of delegation 
in Java is the equals () method. Instead of a 
method trying to figure out if two objects are equal, 
it calls equals () on one of the objects and 
passes in the second object. Then it just gets back 
a true or false response from the equals () 
method. 


Loosely coupled is when the objects in 
your application each have a specific job to do, 
and they do only that job. So the functionality of 
your app is spread out over lots of well-defined 
objects, which each do a single task really well. 




And why is that good? 


A! Loosely coupled applications are usually 
more flexible, and easy to change. Since each 


object is pretty independent of the other objects, 
you can make a change to one object’s behavior 
without having to change all the rest of your 
objects. So adding new features or functionality 
becomes a lot easier. 





dclc^d^bioh. The of or\C okjcd*t -(*o\rY/a\rdm^ dh 
opc\ra*tioh to aho*thcv* okjcd*t, *bo be pcv*-fo\rimcd ov\ 

of objcd*t. 
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more encapsulation 



Design Puzzle Solution 


It’s not enough to know what’s wrong with Rick’s app, or even to figure out that 
we need some more encapsulation. Now^^need to actually figure out how to fix 
his app so we can test it out. / 


The problem: 

Adding a new property to Guitar Spec. java results in changes 
to the code in Guitar. java and Inventory. java. The 

application should be refactored so that adding properties to 
Guitar Spec doesn’t affect the code in the rest of the application. 


Your task: 

o Add a numStrings property and getNumStrings () method to 
Guitar Spec. java. 


TWis is yrtibl 
easy stud. 



public class GuitarSpec 

// other properties 

private int numStrings 





public GuitarSpec(Builder builder, String model. 

Type type, int numStrings, Wood backWood, Wood topWood) 

this.builder = builder; 

this.model = model; 

this.type = type; 

this.numStrings = numStrings; 

this.backWood = backWood; 

this.topWood = topWood; 


// Other methods 


public int getNumStrings() 
return numStrings; 


class 
Guitar¬ 
Spec { Jj 

Num- 

Strings (ji 

GuitarSpec.java 
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Modify Guitar. java so that the properties of Guitar Spec are 
encapsulated away from the constructor of the class. 


public Guitar(String serialNumber, double price. GuitarSpec spec) 
this.serialNumber = serialNumber; 
this.price = price; 

this.spec = spec; 


^ov/, instead m 

七 Wis tohs-tv-ut-tov-. 


Guitar.java 


o Change the search () method in Inventory. java to delegate 

comparing the two Guitar Spec objects to the Guitar Spec class, instead 
of handling the comparison directly. 


public L，st search^ 

LlSt (TteraSr x = guitars . iterator () ； i.has 邮 t() 

for (Iterator _ /mi tar) i . next ()； 

Guitar g ulta = s 」 c () ma lches(searchS P ec)) 
if (guitar .getSpecU - 

m a^chingGuitars.add(guxtar), 

Return matchingGuitars ; 


he sc^hO 
[method got a 
Vt sir^plcv-. 


class 
Inven¬ 
tory { 

search()! 


, p ii t,o&t _|^"if (builder ! = other Spec . builder) 

return false; 

if ( (model ! = null) && (!model • equals ('、〃）） 

(!model.equals(otherSpec•model))) 
return false; 

if (type != otherSpec.type) 
return false; 

= otherSpec.numStrings) 


-fv-om scav-t^O V^as 
fulled ou*t> 
av\d a 

m 今 urtavSpe 乙 java. 


Add— ? 呼如仫 
dass, ^ 一以 java or 

|vwc 灼 W/java. 


if (numStrings 
return false 
if (backWood !: 

return false 
if (topWood != 
return false 
return true; 


otherSpec.backWood) 


otherSpec.topWood) 


&& 


class 
Guitar- 
Spec { 
get- 
Num- 
Stringsi 


GuitarSpec.java 
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test drive 


Owe last test drive 

(and ah app ready for reuse) 

Wow, we’ve done a lot of work since Rick showed us that first version 
of his guitar app. Let’s see if the latest version still works for Rick 
and his clients, and manages to satisfy our own goal of having a well- 
designed, easily maintainable application that we can reuse. 


TW»s »s 

>you should SCC 

WrtM。 toAt ' 


File Edit Window Help ReuseRules 


% java FindGuitarTester 

Erin, you might like these guitars : 

We have a Fender Stratocastor 6-string electric guitar 
Alder back and sides, 

Alder top. 

You can have it for only $1499.95! 

We have a Fender Stratocastor 6-string electric guitar 
Alder back and sides, 

Alder top. 

You can have it for only $1549.95! 


36 a ^oup| c 0 f 
3 ⑷心打铋 ^Koosc 

io Wls cliic dic ^ jc 


f Congratulations! 

Youve turned HicVs broken 
inventoiy search tool into a well- 
designed piece of great software. 
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What wc did 


Let’s take a quick look back at how we got Rick’s 
search tool working so well: 


Wc staged out W ^ 

poWewS Wrth s 

scav*A *tool. 


Wc oh io add some 
molrc -f^hd-tiohali-ty, so 
仏 at the scaui) v-c-tuv-hs a 
lis-fc of Jui-fcav-s. 




1 Make sure your 
software does 
what the customer 
wants it to do. 


tWttes 2. Apply Lask 

y,crc rcaW) J J V 


00 principles to 
add flexibility. 


M also CK»^apsula-tcd out 
■th 3ui-feair piropev-tics, ahd 
wdc su\rc wc (ould add hew 
piropc\rtics -to -the app easily. 




Wc ⑽ added dclqaW - —"^ 
so ouv ofejc 出 a 代 less 
dt^y\dtr\i u\>o^ catV> o 七 V>cv, 

ar\d tar\ be v-cuscd easily- 


3. Strive for a 

maintainable, 
reusable design. 
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ooa&d helps you build great software 


Remember this poor guy? 


He just wanted to write 
great software. So 
what’s the answer? 

How do you write great 
software consistently? 

You just need a set of steps to follow 
that makes sure your software works 
and is well designed. It can be as simple 
as the three steps we used in working 
on Rick’s app; you just need something 
that works, and that you can use on all 
of your software projects. 



We ta\\ 

七 W»s 

ooMV 

(or sV\o\rt- 


Object-Oriented Analysis & 
Design helps you write great 
software, every time 

All this time that we’ve been talking 
about the three steps you can follow to 
write great software, we’ve really been 
talking about OOA&D. 


OOA&D is really just an approach 
to writing software that focuses on 
making sure your code does what it’s 
supposed to, and that it’s well designed. 
That means your code is flexible, it’s 
easy to make changes to it, and it’s 
maintainable and reusable. 
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well-designed apps rock 


OOA^I? is about writing great software, 
wot doing a bunch of paperwork! 


IA/c ’11 talk 

all about 

v-CC\u»v-CwCir>*U 

'm CV^a\>W 2- 


Customers are satisfied when their apps WORK. 

We can get requirements from the customer to make sure that we build 
them what they ask for. Use cases and diagrams are helpful ways to do 
that, but it’s all about figuring out what the customer wants the app to do. 


仙 t 

leaved a bi 七 
dbou*t -fvajilc 
apps alv-cady. 


Customers are satisfied when their apps KEEP WORKING. 

Nobody is happy when an application that worked yesterday is crashing 
today. If we design our apps well, then they’re going to be robust, and 
not break every time a customer uses them in unusual ways. Glass and 
sequence diagrams can help show us design problems, but the point is to 
write well-designed and robust code. 




or\ dclcjat'o^, 
6om\>OS'lt»Oir \, 办 d 

a^v-c^afco^? Well 
-talk about all 
七 m 
CV>a?Ws 气 

ajam m 


Vo^ll io see 
"L^csc pirihtiplcs -■ 

… lly sWfe 

siuH \v\ CKap-tc^ Q. 


Customers are satisfied when their apps can be UPGRADED. 

There’s nothing worse than a customer asking for a simple new feature, 
and being told it’s going to take two weeks and S25,000 to make it 
happen. Using OO techniques like encapsulation, composition, and 
delegation will make your applications maintainable and extensible. 


Programmers are satisfied when their apps can be REUSED. 

Ever built something for one customer, and realized you could use 
something almost exactly the same for another customer? If you do just a 
little bit of analysis on your apps, you can make sure they’re easily reused, 
by avoiding all sorts of nasty dependencies and associations that you don’t 
really need. Concepts like the Open-Closed Principle (OGP) and the 
Single Responsibility Principle (SRP) are big time in helping here. 


Programmers are satisfied when their apps are FLEXIBLE. 

Sometimes just a little refactoring can take a good app and turn it into a 
nice framework that can be used for all sorts of different things. This is 
where you can begin to move from being a head-down coder and start 
thinking like a real architect (oh yeah, those guys make a lot more money, 
too). Big-picture thinking is where it’s at. 


C^ 3 f*tcv-s air>d 1 all about 
lookmj a-t b'lj 
ay\A vcally dcvclofmj a jood 
avd-Kitct-tuvc -fov* vouv a^r»tatioyvs. 


This is ALL 00MVI 

|Vs 朽 。七 dbou*t do*m^ 

sill^ 1 七 s 

abou*t y/v-itmQ killev 

a 代七 ha 七 

leave you\r dus-bomev- 

ar^di you 

-Pcclmg like you^vc 
kicked ass. 
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review and a request 



This is fantastic! I’m selling 
guitars like crazy with this new 
search tool. By the way, I had a few 
ideas for some new features... 


r 

See? VouVc alv-cady 
yttnr'J vc^ucs-ts -fov* 
vnove y/ov*k. R»c.k Will 
-to Wi 七 uirrt_il 
七 hou^v.. weV 30 七 sor»»C 
Ka'iv'icv issues bo m 

七 he yvc%t 乩 a^tev ， 


BULLET POINTS 



♦ It takes very little for something to go wrong with an 
application that is fragile. 

♦ You can use 00 principles like encapsulation and 
delegation to build applications that are flexible. 

♦ Encapsulation is breaking your application into logical 
parts that have a clear boundary that allows an object to 
hide its data and methods from other objects. 

♦ Delegation is giving another object the responsibility of 
handling a particular task. 

♦ Always begin a project by figuring out what the customer 
wants. 

♦ Once you’ve got the basic functionality of an app in 
place, work on refining the design so it’s flexible. 


♦ With a functional and flexible design, you can employ 
design patterns to improve your design further, and 
make your app easier to reuse. 

♦ Find the parts of your application that change often, and 
try and separate them from the parts of your application 
that don't change. 

♦ Building an application that works well but is poorly 
designed satisfies the customer but will leave you with 
pain, suffering, and lots of late nights fixing problems. 

♦ Object oriented analysis and design (OOA&D) provides 
a way to produce well-designed applications that satisfy 
both the customer and the programmer. 


50 Chapter 1 









well-designed apps rock 



OOA&D Cross 

Let’s put what you’ve learned to use, and stetch out your left brain a 
bit. All of the words to answer the puzzle below are somewhere in this 
chapter. Good luck! 



Across 

4. Thssfi help you ovoid soJvfng probJems 

Sotne.Dne 必 , .sc hajS oJreody 

7. Customer^ facus on this part of your 
applicatian^. 

Objects in Eoo^ty coupled appFicQticns are 

more_tha/i tig'h 十 F/ coupled 

9. Flexible applications are Li^ually^asy to 

10. Th^s is one type of code you don't want to 
write. 

32. VoLir apph'co+jons should t»e ea£y to 

13 . Vou: uiL；fllly need sort flf process ts 

write ^reat Software _ - 

14. G.nc^ipdL^atG what_. 

15. These t^pes of applications satisfy 
programmer^. 


Down 

1. Once your applFcatlon works correcrly,. focus 
on t his. 

2. firtsupin^ your appfication Fnto logical parts, 

3. The goal of OOAAD tc- help you write this 
type of Software. 

5. Udc ihid to let abject^ focuo on mort 
Specific tasks. 

6. A good way to avoid duplicate code 

7. An cippFication that thifigs can go wrtmg rn 
easily. 

11. This is a four fetter word your mopn wil? be 
proud you know. 
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exercise solutions 


命 





命 


命 


You’ve learned a lot about writing great software, and there’s still more to 
go! Take a deep breath and think about some of the terms and principles 
we’ve covered. Connect the words on the left to the purpose of those 
techniques and principles on the right. 


feiBiLitS 


Encal>SiiLatipH 


fliHctipHaLitS 


Design Vattew 



Without me, you\\ neVer actually make the 
customer fcapp/. Nq matter how Well-designed youv 
application is, Tm tie thing tfcat puts a smile on 
the customers face. 

rm all about reuse and making sure youve not 
trying tQ solve a problem iMt someone else has 
already figured out 

Yqu use me tQ keep the parts of youv code tMt 
sta/ the same separate from the parts ttat change ； 
then its really eas/ tQ make changes tQ /our code 
Without breaking everything. 

Use me so tfcat /our software can change and grow 
without constant rework. I keep youv application 
from being fragile. 
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well-designed apps rock 


Sharpen your pencil 

K answers 


oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo 


What would you change about this code? 


丁 here’s a big problem with the code shown above, and it’s up to you to figure it out. In 
the blanks below, write down what you think the problem is, and how you would fix it. 


Every time a new property is added to fruitarSpec.iava, or the methods m fruitarSpec change, 

the searchO method m luvcHtoryJava will have to change, too. Wc should let fruitarSpec handle 

comparisons, and encapsulate these properties away from Inventory. 


TWis is〆 七 vcv-y jood 
dti\yr\- Evcvy 
a y^cv/ \>v-o\>cvtY 一 
is added *to 

今 tWis 

todt is jo'mj -to 
V^avc "bo 


public List search(GuitarSpec searchSpec) 

List matchingGuitars = new LinkedList(); 
for (Iterator i = guitars.iterator(); i.hasNext(); ) { 

Guitar guitar = (Guitar)i.next(); 

GuitarSpec guitarSpec = guitar.getSpec(); 
if (searchSpec.getBuilder() != guitarSpec.getBuilder()) 

continue; 

String model = searchSpec.getModel().toLowerCase(); 
if ( (model ! = null) && (!model. equals ('、〃））&& 

(!model.equals(guitarSpec.getModel().toLowerCase()))) 
continue; 

if (searchSpec.getType() != guitarSpec.getType()) 

continue; 

if (searchSpec.getBackWood() 
continue; 

if (searchSpec.getTopWood() !: 

continue; 

matchingGuitars.add(guitar); 


: guitarSpec.getBackWood() 
guitarSpec.getTopWood()) 


return matchingGuitars 


^ Inventory.java 

calces t Wo 9 oh 

^ /ou you, dJs t J r h 

卜 。 W ijobs J S ot!°l 5 ° h 

4 d ^ wo " y aUi y- 
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Everybody loves a satisfied customer. You already know 

that the first step in writing great software is making sure it does what the 
customer wants it to. But how do you figure out what a customer really 
wants? And how do you make sure that the customer even knows what 
they really want? That’s where good requirements come in, and in this 
chapter, you’re going to learn how to satisfy your customer by making 
sure what you deliver is actually what they asked for. By the time you’re 
done, all of your projects will be “satisfaction guaranteed,” and you’ll be 
well on your way to writing great software, every time. 


Give Them What 

They Want 


I hope you like it... Ive been 
paying attention to every word 
youVe said lately, and I think 
this is just perfect for you! 


2 gathering requirements 


this is a new chapter 








welcome to the big leagues 


You’ve got a wew programming gig 

You’ve just been hired as the lead programmer at a new start-up, 
Doug’s Dog Doors. Doug’s got a pretty high-tech door under 
development, and he’s decided you’re the programmer that can 
write all the software to make his killer hardware work. 


Tired of cleaning up your dog’s mistakes? 

Ready for someone else to let your dog outside? 

Sick of dog doors that stick when you open them? 

It’s time to call... 

Doug’s Dog Doors 


★ Professionally 
installed by our 
door experts. 

★ Patented 
all-steel 
construction. 

★ Choose your own 
custom colors 
and imprints. 

★ Costow-cot door 
for your dog. 


HevVs 七 he hew sales 
*msc\rt \ruKmmg 
m all -the Sunday 
papev-s 七 his v/cck. 




Every night, Fido barks and barks at 
the stupid door until we let him go 
outside. I hate getting out of bed, and 
Todd never even wakes up. Can you 
help us out, Doug? 


O 


Call Doug today at 


1-800-998-993i 


o 


Todd 


Todd and your 
first customer 

Todd and Gina want more than a “normal” 
doggie door. Todd has everything from his plasma 
TV to his surround sound stereo to his garage 
door operating off of a remote control, and he 
wants a dog door that responds to the press of 
a button. Not satisfied with a little plastic flap 
letting their dog in and out, they’ve given Doug’s 
Dog Doors a call... and now Doug wants you to 
build them the dog door of their dreams. 
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gathering requirements 


Let's start with the dog door 

The first thing we need is a class to represent the dog door. Let’s call this class 
DogDoor, and add just a few simple methods: 


public class DogDoor 


private boolean open; 


Assume the P 03 D 00 V- C\ass will 

Dou 3 Wul 

hairdwav-c. 


public DogDoor() { 

this.open = false 

} 


TW’s ’s public void open () { 

s'»wflc ： System. out. print In (''The dog door opens .’’）； 

o^cv\s *tV^c do 饮 … 


open 


true 


… 扣 d doseO 

ihc doom. 


public void close () { 

System. out. print In (''The dog door closes •〃）； 
open = false; 

} 


TW\s 

{\\t s*ta*tc 
of doov * ： 
y/Kc-t^cv- i*t’s 
o^cr\ ov* dosed- 


public boolean isOpen() 
return open; 

} 




All 七 Wis todc.. 


… goes ih-fco 
DogPoo\r.java.. 




class ^^1 
DogDoor I 

open ()1 



DogDoor.java 


...y/W»tK y/ill Cov\bro\ 
-tKc V^av-dv/av-c m 
Todd a^d 4 ma ’ s 
do^ doov. 


a^d 70UV- boss, po^- 
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writing the dog door code 



Code Magnets 


Let’s write another class, Remote, to allow a remote control to 
operate the dog door. Todd and Gina can use the remote to 
open the dog door without having to get out of bed. 

Be careful... you may not need all the magnets. 


we khow this is a ^lly 

cass / ° hC * ^Vc just getting 
you wavmcd up, doh't wovvy. 


public class Remote 


private 


door 


public Remote(_ 

this.door = door 


public void pressButton() { 

System.out.printIn(''Pressing the remote control button 


if ( . 

()){ 

door. 

0 ； 

} else { 


door. 

0 ； 


Once you’re done, compare your answer wifli ours on page lo8_ 


the methods 

you wvo-tc -to 匕 Ohtvol 
七 he dog doov*. 





—dlass ^ttds a little Zt is 

book 扣 \oyt, 叫 ht? or d)oscd . 


You cav\ use {\\tst {p 
do^ door objcd*t- 
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gathering requirements 


Test drive 


Let’s see if everything works. Go ahead and take your 
new dog door for a test drive. 

o Create a class to test the door (DogDoorSimulator.java). 


public class DogDoorSimulator { 

public static void main(String[] args) { 

DogDoor door = new DogDoor(); 

Remote remote = new Remote(door); 

System, out. print In (''Fido barks to go outside .. 
remote.pressButton(); 

System, out .print In (''\nFido has gone outside... 
remote.pressButton(); 

System, out. print In (''\nFido A s all done...’’）； 
remote.pressButton(); 

System, out. print In (''\nFido A s back inside...’’）； 
remote.pressButton(); 


)； 



DogDociSimulator.java 


❺ Compile all your Java source code into classes. 


DogDoor.java 
Remote.java 
DogDoorSimulator.java 


卜 _ 产 6 * Q aVa 





咖 r Ok DogDoor.class 


it 




I ⑽ 

mold 

⑽训 

ioloUL 


Remote.class 

DogDoorSimulator.class 


o Run the code! 


■ File Edit Window Help Woof_I 


% java DogDoorSimulator 
Fido barks to go outside... 

Pressing the remote control button... 
The dog door opens. 

Fido has gone outside... 

Pressing the remote control button... 
The dog door closes. 

Fido f s all done... 

Pressing the remote control button... 
The dog door opens. 

Fido f s back inside.•• 

Pressing the remote control button... 
The dog door closes. 


It works! Lef s go 
show Todd and toa 
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a broken dog door 

Put whew ftiwa tried it. 




Sharpen your pencil 



How do you think the rodents are getting into Gina’s 
kitchen? In the blanks below, write down what you think is 
wrong with the current version of the dog door. 


used ihc doo^ p ido 


So 



Do^i 50 *to *bV^c 於乂七州 c 
u^l you’ve Y/^*b*bcyv do^iv\ 
dy> ayvSY/cv (or wv-tisc. 
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gathering requirements 


Theres nothing wrong 
with our code! Gina must have 
forgotten to press the button on 
the remote again after Fido came 
back in. IYs not my fault shes 
using the door incorrectly! 


But the door doesn’t work the 
way Todd and Gina want it to! 

Todd and Gina didn’t expect to have to close 
the dog door, so they pressed the button on 
the remote only once: to let Fido out. 

Even worse, in this case, the way they used the 
door created new problems. Rats and rabbits 
started coming into their house through the 
open door, and you’re taking the blame. 

Let’s tackle Todd and Gina’s dog door again, 
but this time, we’ll do things a little bit 
differently. Here’s our plan: 


O 

❺ 

❺ 

o 


Gather requirements for 
the dog door. 


Figure out what the door 
should really do. 


Looks like wcVc goihg -to spchd 

lot -time -blkihg with Todd 

^\y\S -this -tinr»c dlrouhd. 


a 


J 


Get any additional information 
we need from Todd and Gina. 



1 Make sure your 
software does 
wkat tke customer 
wants it to cto. 
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what is a requirement? 


So wkat exactly is a recruirement, anyway? 


A is usually 

a sjhj[c thihg, ahd you 

that ihih^ 

you’ve 

actually Killed the 


Ifs a 


specific thing 


your 


1 sys*tcm W IS {\\t domflctc apf 

ov pv-ojcd*t youVc y/ovknr^ cm. 

I 於 i\\\s tasc, Y 。 价 system is 

Todd a^d <Ws Coptic doj 
Joov sc*tuf mtludcs *tV^ 

v-cw>o*tc £.or\*tv"ol> by *t^c v^) 


t 


system 

has to 

do 

to 


J]_ e d p do<xr system, has io ''do" 


lo ^ <>f thih 


3 s : opA dose, Id 


P . , , ^ TV 1 C 

^do oui keep ^is 

TAaTI^' 叫仏叫七 W 

Y ^ Co ^ with is 

P ^ <^P what -the system u d ocs . J 


work correctly. 


Rcrhcmbc\r, the ^usWv- decides wheh a sysie^ 
wovks to^YteiVj. So i-P you leave out a 

丄 I 士 ihey -ro\rgct "to mchtioh somethihg "to you, 
terw ish ■(: wo\rkih0 


o\r CVCh 
tliC syst< 


rSeM^sCo?^ 



vc^uircmc^t A V'C^uiv-cmCh-t is a sih^ular v\Ctd drtailmg 
y/hd*b d p3\rtidul3v p\rodud*t o\r sev-vide should be o\r do¬ 
lt is mos 七 dorwmohly used m d -formal schsc m 
sys-ber^s Ch^ihCCV-ih^ o\r so^*t>/3V"C Ch^ihCCV'm^. 
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gathering requirements 


Listcw to the customer 


When it comes to requirements, the best thing you can do is let the 
customer talk. And pay attention to what the system needs to do; you 
can figure out how the system will do those things later. 


Pcm’t … ovr7 
about 

todt at *tWis 

wake 

system 

should 


Wh^ Todd 


iirto 


Fido^ about a foot tall, and we don’t 
want him having to hurt his back 
leaning over to get out the door. 


Gina: And we want the door to automatically close after a few 
seconds. I don’t want to have to wake back up in the middle of 
the night to close the door. 

You: Do you want a single button on the remote, or both an 
‘Open’’ and “Close” button? 

Todd: Well, if the door always closes automatically, we really 
don’t need separate “Open” and “Close” buttons, do we? Let’s 
just stick with a single button on the remote control. 

You: Sure. So the button opens the door if it’s closed, and it can 
also close the door if it’s open, just in case the door gets stuck. 

Todd: Perfect. Gina, anything else you can think of? 

Gina: No, I think that’s it. That’s the dog door of our dreams. 


HcvVs youv sc*b of 
yrcmo-tc do^ol do^ 
door pUs, based ov. Todd 

^*mas rc<\\Airc^is- 






Remote Control 
yzr .2 


TKcmcsjust OhC but-toh, 
wkh toggles between 
opch'mg 5h d dosing the doov-. 


O 



Pog Poor ver: 2 



"This opehih^ 

^ceds {jo be at 

\r ul 

So Pido docs^i 
u lcah. w 
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a simple requirements list 


Creating a requirements list 

Now that we know what Todd and Gina want, let’s write down our new 
set of requirements. We don’t need anything too fancy... 


Com^av-c -tV^CSC 
Y/’rtV> lodd 
av\d s 

ov\ 

A … 

sec ho>M >wc 
-tuvyxcd 
Y/ovds m*to a 
bds'16 sc*t oi 


Todd awd Nina's Poq Poor: version 2.0 

Requirements List 

1. The dog door opening must be at least 1 T tall. 

2. A button ov\ the remote control opens the dog door 
if the door is closed, and closes the dog door if the 

door is open. 

$. Once the dog door has opened, it should close 
automatically if the door isn't already closed. 


We'll just dlosc i\\t door 
a Jf c >w sc6ov>ds be ” 。?加 


This is jus*t d lis-fc 

°*f "the "th'mgs 

"that youv- ^us-fcoi 
wahts the system 
yot»Ve buildihg 
"them -fco do. 






A special bonus prize 


In addition to having a list of things you need to do to 
complete Todd and Gina’s dog door, now you can show 
your boss exactly what you’re working on, and what work 
you think is left to finish the project. 


P 吩 … 3ddiii 0 ^l 

^^c^chis ^Losi 
° h ^ P^oj^i 7 
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gathering requirements 


卜 Todd av>d 
^'mds tasc, *t^c 

»s *b^c do^ 

doov- dy\d 七 ^ 
v-cwo*bc to^*bv-ol. 


Is this list really going to 
help? Todd and Gina completely 
forgot to tell us they wanted the door 
to automatically close before... won’t 
they just forget something 
again? 


O 


You need to understand how 
the dog door will be used. 

You’ve figured out one of the hardest 
parts about getting a customer’s 
requirements —— sometimes even the 
customer doesn’t know what they really 
want! So you’ve got to ask the customer 
questions to figure out what they want 
before you can determine exactly what 
the system should do. Then, you can 
begin to think beyond what your customers 
asked for and anticipate their needs, even 
before they realize they have a problem. 




arpen your pencil 


What sorts of things do you think Todd and Gina might not have 
thought about when it comes to their new dog door? Make a list 
of any concerns you might have in making sure Todd and Gina 
are happy with the new door you’re building them. 
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figuring out what todd and gina need 

What does the dog door really weed to do? 

You know what Todd and Gina want the dog door to do, but it’s your job to 
make sure that the door actually works. In the process, you may even come across 
some things that Todd and Gina want, but didn’t think about on their own. 

Let’s write down exactly what happens when Fido needs to go outside: 




Wcircs youv 

list 

厶午 . 


Todd awd ^ma's Poa Poor, version 2.0 

list 


This is 9 hew 
list, wh'uih details 
what the dog doov- 
actually does. 


2. A 


todd and finals l?oq l?oor vgrs i ⑽ 2.0 
What the Poor Poes 

1. Fido barks to be let out. 

么 Todd or hears Fido barking. 

多 • Todd or ^iwa presses the button on the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business, 
fido goes back inside. 

及 The door shuts automatically. 


use 

"these steps -to 

s ^c i-p wcVc 
•^issihg dhy 


W\\tY\ stef ^ is domflctc, Fido^s \)BCk 
mside a+*tcv his business, and 
Todd av\d 6j\v\a avc happy. 
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gathering requirements 



So a requirement is just one of 
the things that a customer wants the 
application you build for them to do? 


e no 


Questions 


I don’t see why I have to figure out 
how Todd and Gina are going to use the 
dog door, and what can go wrong. Isn’t that 
their problem, not mine? 


Actually, a requirement is a lot more 
than just what the customer wants—although 
that’s a good place to start. Begin by finding 
out what your customer wants and expects, 
and what they think the system you’re building 
for them should do. But there’s still a lot more 
to think about... 

Remember, most people expect things to 
work even if problems occur. So you’ve got 
to anticipate what might go wrong, and add 
requirements to take care of those problems as 
well. A good set of requirements goes beyond 
just what your customers tell you, and makes 
sure that the system works, even in unusual or 
unexpected circumstances. 


A! Do you remember the first step we 
talked about in writing great software? You’ve 
got to make sure your app works like the 
customer wants it to—even if that’s not how 
you would use the application. That 
you’ve got to really understand what the 
system has to do, and how your c 
are going to use it. 


at means 
lat the 
ustomers 


In fact, the only way to ensure you get Todd 
and Gina a working, successful dog door is 
to know the system even better than they do, 
and to understand exactly what it needs to 
do. You can then anticipate problems, and 
hopefully solve them before Todd and Gina 
ever know something could have gone wrong. 


Tke test 

way to 
get good 
requirements 
is to 

uncierstanct 


And the system for Todd and Gina 
is just the dog door, right? 


A! The system is everything needed to 
meet a customer’s goals. In the case of the 
dog door, the system includes the door, but it 
also includes the remote control. Without the 
remote, the dog door wouldn’t be complete. 

And even though they aren’t part of the 
system, Todd and Gina and Fido are all 
things you have to at least think about when 
designing the system. So there's a lot more to 
worry about than just the actual dog door. 


So I should just come up with all 
sorts of bad things that might happen when 
Todd and Gina use their door? 


A ： 


Exactly! In fact, let’s do that now... 


wliat a 
system is 
supposed 
to do. 


you are here ► 


67 


what can go wrong will go wrong 


Flaw for things going wrowg 

Below is a diagram of how Todd and Gina’s dog door should work; all 
the numbers match up with the steps in our list on page 66. But things 
aren’t always going to go according to plan, so we’ve written down some 
things that might go wrong along the way. 





I 七 \\(XO IS SXAAtR 

Todd 

Wim fea^rk *to \>vcss 
cm 七 \rcwoie le 七 

\\\n\ b 3 tk i^? 


® The door shuts automatically 


Gina, open the dog 
door... Fido won’t 
quit barking! 


① Fido barks to be let out 

r 

pocs f \do aUays 

bavk v/V^cv\ V^c 灼 ccds 

{p ou*b'»dc? WV^a-b 

•,jf V^c jus 七 straicMts 
a 七七 doov? 


^ i-P Todd a, d 

^ir Rdo b^vkihg? 


(§) Todd or Gina hears Fido barking 
⑧ Todd or Gina presses the button on 


the remote control. 


r V ^ 七 』 pido kav-ks because V^c s 

ov U^y? m\ *»*t kc a 

roblcr, i-f Todd av>d 

door ay>d F^do dot^ i ^ccd 

r% HA OU ilSldC . 
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Ca "； y° u 仏 K>k J othcv^ ihihas 

m 3 。 W^ 9 ? Thats 3〆 th 〜代 

p.oble.s you thi,k ^ the less 4aaile 

IZ dah x ^ akc Y ou,r ^pl'^tioh. ahead 

3hd w ， rr, ih 9 dsc - 吵 t happe, 

Uhe^dly below, di^tly o, |he diag,^. 



Kaffcr\s i-f iiic door 
lids au*to 眯 a*ti 乙 ally dloscd by 
•tKc tiw'C Fido is -fihisKcd? 


© Fido does his business 


⑦ Fido goes back inside' 


you are here ► 


69 




expect things to go wrong 


Alternate paths handle system problems 

Now that you’ve figured out some of the things that can go wrong, you 
need to update your list of things that needs to happen to make the 
dog door work. Let’s write down what should happen if the door closes 
before Fido gets back inside. 


This is -that same 

l,st ^ may 

update these \at^ 
but W how, ihcyVc still 0^. 


Wc use -thcscl 
U sub—hurwbcv*s ,； -to 
show some sub- 
s-teps ihai rwighi 
happen as pav-i 
o( St—. 

|Jf p«do stays 
ou-b'idc, -bV^eve avc 
a -fev/ add ， W< 
steps \rc<\u'»v-cd 
-to yb W»w batk 
inside* "TV^ese 
C% 七 va stc\>s 
avc tailed 


Todd aytd Nina's l?oq Poor: version 2.0 

^Requirements List 


1 . 


2 



T_ Todd and finals l?oq Poor vgrs i ⑽ 2.0 

What the Poor Poes 

1. Fido barks to be let out. 

么 Todd or Gina hears Fido barking. 

; 0 多 • Todd or 备 iwa presses the button on the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

®The door shots automatically. 

6.2 Fido barks to be let back inside. 

6.3 Todd or ^ina hears Fido barking (again). 

6.4 Todd or ^ma presses the button on the 
remote control. 

6.5 The dog door opens (again). 

Z Fido goes back inside. 

8. The door shuts automatically. 


All o( Y\t^l 

steps iidy\dilc 七 he 

pvoblcm o-f 
door tlos'm^ bc-fovc 

Fido jc*b batk 
mside house. 


^ ^dded, Fi ( 
r sidc ；i ^ iho M 

l^oble^ Todd d 
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gathering requirements 



Hey, I took a course in college 
on this stuff... aren’t we just 
writing a use case? 



Yes! You’ve been writing 
use cases all along 


When you wrote down the steps in getting 
Fido outside to use the bathroom, you 
were actually writing a use case. 

A use case is what people call the steps that 
a system takes to make something happen. 
In Todd and Gina’s case, the “something” 
that needs to happen is getting 
Fido outside to do his business, 
and then back inside. 


Look/ /-t s a 


use case. 


Todd and ^iwas Poq Poor ： version 2 0 

What the Poor Poes 


1. Fido barks to be let out. 

么 Todd or ^ina hears Fido barking. 

多 .Todd or ^ina presses the button on the 
rewote control. 

4. the dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shots automatically. 

6.2 Fido barks to be let back inside. 

Utodd or(Mwa hears Fido barking (again). 

6.4 Todd or 备 ina presses the button on the 
remote control. 

6.5 the dog door opens (again). 

Z Fido goes back inside. 

孓 The door shots automatically. 


x/ouve attually aWtad^ 
*bV^c use case 
Todd av>d 知 a’s _ door. 
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whafs a use case? 


(Re) introducing use cases 

You’ve been writing a use case for almost 10 pages now, but let’s take a 
closer look at exactly what that list of steps — the use case for Todd and 
Gina’s dog door — is really all about: 


A use case describes 


Use ^ascs all 
UaV ， docs 

a _ 毗 咖 • 


what 

your system 


does 

to accomplish a 

particular 


I^Vc v-c s-fcill de^fihi 七 ely 
-fodusihg oh what the system 
■&> u do. w IVhat should 
happen m oYdcr io get Fido 
outside (a^d thch ba^k ih-to 
"the house)? 


{o£aa scS 

h c Aoa \ 丁 k 

1 g^Todd 

customer goal 


|jf Todd av^d dc 6 ，dc 
七 V\eY 叫办七 k V^oy/ 

md ^7 -t^cs f 'ldo uses i\\t 

dooydoov, ^at^ould ^a 

dvWcrsri 5 ° a1, so V ou d ^ 

a^cv, usc 6asc， 


c 

TV,e use ， U usevs^ 

七 V^c svstem, l^ot a ?” ， , . , r 
a；d s^s also o 办 de oUk ^ 
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gathering requirements 


TV\c cy\*tiV"C ^ 乙 asc 

describes ^a*t *t^c 

door docs >N\\ty\ F\do 
Y\ccds -to 50 ou*U«dc- 



TV>c use tasc cmds 4 ⑼ 
七 V^c 6us*towcv <y>a\ »s 

domfs ndo 

badk ms«dc, a^-tev- 
dio'm^ W»s kus'mess, 

Todd and ^ 
domWtaWc m bed ， 


Todd and Nina's l?oq Poor version 2.0 
What the Poor Poes 

1- Fido barks to be let out. 

2 . Todd or friwa hears Fido barking. 

炙 Todd or frina presses the button on the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back inside. 

6.? Todd or (Mna hears Fido barking (again). 

6.4 Todd or frina presses the button oh the 
remote control. 

6.5 The dog door opens (again). 

1 , Fido goes back inside. 

8. The door shuts automatically. 


This is ah 
slie^sic path, 

but its still 
3bout 3dliievih0 
the s 3 rme ^oal as 
the rn^ih path, so 
it's pairt of ihc 
use 


Sc 5 plafsCotner 



use d3sc* A use ddse is a "bcdhhi^uc -for *tiic 

po*bch*tial \rc^ui\rCmr\Ch*U d hC>/ sys-bcinr\ ov so-f*t>/3\rc dlidh^e- 
use ddse pv-ovidcs ohC or tonorc sdeh3\rios *tha*t dohvey hoy/ 
■the sys*tcm should ih-bev"ad*fc y/i*th *thc tv\d usc\r or 

sys-tem -to achieve a spedi-fid ^oal 
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one use case, three parts 

One use case, three parts 

There are three basic parts to a good use case, and you need 
all three if your use case is going to get the job done. 



TV^c use 6 asc 
must 
Todd 

deal 

Y/i*bV\ 


tlear Value 


livery use clear 

value to the system. If the use case 
doesn’t help the customer achieve theil 
goal, then the use case isn’t of much use. 


U f? ^ up 

\ hch Fi do b^ks... it 
^ he's \y,s\d C) P 

dohc ^ ^ U 咖 . 


Start and Stop 


STOP 


卜七 V^c do^ door, 
pido is tV'C 
e% 七 wal m’rba*tDV. 
He 、 >/V\ 3 *t s*t 3 v**ts 

i\st cA 代 \>v-o 6 CSS 




Every use case must have a definite 
starting and stopping point. SometlTTTT^ 

must begin the process, and then there must be a 
condition that indicates that the process is complete. 


External Initiator 


Every usecaseisstarteaonDyarrexternar 
initiator, outside of the system. Sometimes 
that initiator is a person, but it could be 
anything outside of the system. 
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gathering requirements 



Use Case Magnet 


s 

Below is Todd and Gina’s use case, and a magnet for each of the 
three parts of a good use case (one part. Start and Stop, actually 
has two magnets). Your job is to identify where each magnet 
goes and attach it to the right part of the use case. 


Todd and Nina's Pog Poor, version 2.0 

What the Poor Poes 

1. Fido barks to be let out. 

2 . Todd or &ma hears Fido barking. 

$• Todd or friwa presses the button on the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back mside. 

6_3 Todd or hears Fido barking (again). 

6.4 Todd or friwa presses the button ow the 
remote control. 

6.5 The dog door opens (again). 

1 Fido goes back inside. 

S. The door shuts automatically. 





STOP 


pu*t Super Buy 

or\ use 

tasc »s tlcav value 

*to a 灼 (i 


»*b 

oy \ 七 he 
i\\t use 匕 

七 ha 七 mdi^ates 
七 he pv-otess 
should stof. 



伽 stav-*b 
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should be \rcally easy... 
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ease? This is usually 
some adtioh outside o-f 
the system. 


use cast 
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the parts of a use case 



Use Case Magnet Solutions 

Below is Todd and Gina’s use case, along with several use case 
magnets. Your job was to identify where each magnet goes, and 
attach it to the right part of the use case. 


Jk 




I 


TW«s »s i\\t start 

Jc ^ ^ st， 
No 七 be— s 


Todd ayid (r\m J s Poq Poor ： version 2.0 

What the Poor Poes 


l(Fjdo)barks to be let out. 

2. Todd or (r\m hears Fido barking. 

$. Todd or (r\m presses the button ow the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back inside. 

6 •多 Todd or (rim hears Fido barking (again). 

6.4 Todd or friwa presses the button ow the 
remote control. 

6.5 The dog door opens (again). 

7 Fido goes back inside. 

S. The door shuts automatically. 


Fido is -the 
•m -this use ddse- 



ttcvc^s 七 he s*fcop 
dondrtior\-. 

Fido is badk \y\, 
dr>d Aoo\ 
is dosed. 


c, 


STOP 


use 
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gathering requirements 



e no , 

Questions 




So a use case is just a list of the 
steps that a system has to do to work 
correctly? 

In most cases, yes. But, remember, 
one of the key points about a use case is 
that it is focused on accomplishing one 
particular goal. If your system does more 
than one thing—like let Fido outside and 
track how many times he’s been out in an 
entire day—then you’ll need more than one 
use case. 

Then my system will have a use 
case for every goal it accomplishes, 
right? 

A: Exactly! If your system just does one 
single thing, you’ll probably only need one 
use case. If it does ten or fifteen things, then 
you’re going to have a lot of use cases. 






And a use case is what the system 
does to accomplish a goal? 

Now you’ve got it. If you write down 
what the system needs to do to perform a 
task, you've probably got a use case. 


But the use case isn’t very 
specific. Why didn’t we talk about the 
Remote class or the DogDoor class? 

Use cases are meant to help 
you understand what a system should 
do—and often to explain the system to 
others (like the customer or your boss). If 
your use case focuses on specific code¬ 
level details, it’s not going to be useful to 
anyone but a programmer. As a general 
rule, your use cases should use simple, 
everyday language. If you’re using lots of 
programming terms, or technical jargon, 
your use case is probably getting too 
detailed to be that useful. 




Is a use case the same as a use 
case diagram? 

A: No, use cases are usually a list 
of steps (although you can write them 
differently, something we talk about in the 
Appendix). Use case diagrams are a way to 
show use cases visually, but we've already 
been working on our own diagram of how 
the system works (check out page 69 for 
a refresher). Don’t worry, though, we’ll still 
look at use case diagrams in Chapter 6. 


Then how do I turn my use case 
into actual code? 

That’s another step in the process 
of writing your application. In fact, we’re 
going to look at how to take our use case 
for Todd and Gina and update our code in 
just a few more pages. 

But the purpose of the use case isn’t to 
detail how you’ll write your code. You’ll 
probably still have to do some thinking 
about how you want to actually put the 
steps of your use case into action. 

If the use case doesn’t help me 
write my code, then what’s the point? 

Why spend all this time on use cases? 

Use cases do help you write your 
code—they just aren’t specific about 
programming details. For instance, if you 
didn’t write a use case for Todd and Gina, 
you never would have figured out that Fido 
might get stuck outside, or realize that the 
dog door needed to close automatically. 
Those all came from writing a use case. 

Remember, you'll never write great software 
if you can’t deliver an app that does what the 
customer wants it to do. Use cases are a tool 
to help you figure that out—and then you’re 
ready to write code to actually implement the 
system your use case describes. 
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did you cover all the features? 


Checking your requirements 
against your use cases 

So far, you’ve got an initial set of requirements and a good solid 
use case. But now you need to go back to your requirements and 
make sure that they’ll cover everything your system has to do. 
And that’s where the use case comes in: 


Todd and Nina's Poq Poor: version 2.0 

Requirements List 

1. The dog door opening must be at least 1 T tall. 

么 A button on the remote control opens the dog door 
if the door is closed, and closes the dog door if the 
door is open. 

3. Once the dog door has opened, it should close 
automatically if the door isn't already closed. 


Is anything missing? 

Now you need to look over the use case and see 
if everything the system needs to do is covered by 
the requirements. 




(ic\rc ； s ou\r list o-p \rc«\uiv-CrwChts 

that wc got -fv-om Todd a^d 与 ma … 


...a^d Kcvc^s y/Ka*t 

doov r>ccds *to do- 


Todd and frina's Pog Poor, version 2.0 

What the Poor Poes 

1. Fido barks to be let out. 

2. Todd or &ina hears Fido barking. 

3 . Todd or friwa presses the button on the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back inside. 

6 •多 Todd or friwa hears Fido barking (again). 

6.4 Todd or friwa presses the button on the 
remote control. 

6.5 The dog door opens (again). 

1 Fido goes back inside. 

8. The door shuts automatically. 
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iQrpen your pencil 

^ Do your requirements handle everything? 

Below on the left is the list of things that the dog door does, pulled straight 
from our use case on page 78. Your job is to identify the requirement that 
handles each step of the use case and write that requirement’s number 
down in the blank next to that step of the use case. If a step in the use case 
doesn’t require you to do anything, just write N/A down, for “not applicable”. 


Todd and Gina’s Dog Door, version 2.0 

What the Door Does 

1. Fido barks to be let out. 

2. Todd or Gina hears Fido barking. 

3. Todd or Gina presses the button on the 

remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back inside. 

6.3 Todd or Gina hears Fido barking 
(again). 

6.4 Todd or Gina presses the button on 

the remote control. 

6.5 The dog door opens (again). 

7. Fido goes back inside. 

8. The door shuts automatically. 


Wert arc -tiiv-cc vemeirrb 从 

…於认 试 any -fov 

eaA m use CBsc 

2.0 

Kcquiremehfs List 

1 irt°a1| door _ f __ e at —st 
2, 0Yl the r _ ote control opens 

the dog door ff the door fs closed Ld 

closes the dog door if the door is open. 

$，d ? or has opened, it should 


七 c I, Z, \ ox U/h 
m catK o-f Wanks. 



Did you find any steps in the use case that you don’t think 
you have a requirement to handle? If you think you need 
any additional requirements, write what you think you need 
to add to the requirements list in the blanks below: 
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inquiring minds want to know 


t^harpen your pencil 

、 v answers 


Do your requirements handle everything? 


Below on the left is the list of things that the dog door does, pulled straight 
from our use case on page 78. Your job was to identify the requirement that 
handles each step of the use case, and write that requirement’s number down 
in the blank next to that step of the use case. You should have written down 
N/A for a step that didn’t require our system to do anything. 


Todd and Gina’s Dog Door, version 2.0 
What the Door Does 

1. Fido barks to be let out. 

2. Todd or Gina hears Fido barking. 

3. Todd or Gina presses the button on the 

remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back inside. 

6.3 Todd or Gina hears Fido barking 
(again). 

6.4 Todd or Gina presses the button on 

the remote control. 

6.5 The dog door opens (again). 

7. Fido goes back inside. 

8. The door shuts automatically. 


Ml 

N/A 

2 


2 


— 


… do , hythjh3 



_you N/A 

smtc *tV^c button 

七 so 州 tV.aVs you Kavc 
-to hdle … 2- is 
-too, smte …。认七 a 

button a 代州 o*tc. 

you get this Fido 

丄七 〆 outside i-f the opehiha 
•Sh 七 the v-ight siic. 

T\,t ^ould 

V^avc cas7 out ^ 

out v-c^vcm^ts 

■fov ? a ^* 




Did you find any steps in the use case that you don’t think 
you have a requirement to handle? If you think you need 
any additional requirements, write what you think you need 
to add to the requirements list down in the blanks below: 

No, our requirements cover everything the system needs 

to do. WeVe ready to actually write code to handle these 

requirements mow, right? 
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gathering requirements 


So now can we write some code? 

With use case and requirements in hand, you’re ready to 
write code that you know will make Todd and Gina satisfied 
customers. Let’s check out our requirements and see exactly 
what we’re going to have to write code for: 


TVis »S 

Pou^ 3y\d *tV\c 
Kav-d>wav-c 
dcdl 

yjc do 於’七 need 
BY\y todc (or 
七 Wis 





TWis *»s Aa 七 Todd 
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r\ccd *to …矿如 
toAt take 6avc 
oJf dosmoy i\st door 

au*tow'3*t , ^3^7 , 


Todd and Nina's Poq Pooc version 2.0 

Requirements List 

1. The dog door ope^mg must be at least 1 T tall. 

2. A button ow the remote control opens the dog door 
if the door is closed, and closes the dog door if the 
door is opeh. 

3. Ohce the dog door has opened, it should close 
automatically if the door isn't already closed. 



Were getting pretty psyched 
about our new door. We love that 
you thought about Fido getting 
stuck outside, and took care of 

that, too. 


lA/c^vc al\reddy 

got Code -fco 
take C^rt this 
V-C<\ui\rCmCh-t. 









adding a timer to the dog door 


Automatically closing the door 

The only requirement left to code is taking care of 
automatically closing the door after it’s been opened. Let’s go 
back to our Remote class and handle that now: 



Remote.java 


import java.util.Timer; 
import java.util.TimerTask 

public class Remote { 

private DogDoor door; 



heed ihese ^ Wo 
usc 山 va ' s 6*^3 Masses. 


This checks -the 

siaic o( the 
doo\r bc-Povc 
opchihg or 

dlosihg i*t. 


public Remote(DogDoor door) 
this.door = door; 


public void pressButton () { 

System. out. print In (''Pressing the remote control button . 
if (door.isOpen ()) { 

door, close () ; ^ 3 | 代 3 幻 has Code b> 

V.d^ale tlosma door o ? cv^. 


Create a 

so 

do^ Aoor 
tW 崎 


n 


else { 
door.open () 


final Timer timer = new Timer(); 
timer.schedule(new TimerTask() { 

public void run() { 

door.close (); 


All the -fc^sk docs is close 

七妹 卜 ahd th ⑶ 

the -timev-. 


timer.cancel() 


}, 5000); 


This idls ihc ^ I 
Wh 毗 -s 弓 00 。 ^ ^ '從味 


ls C^oy\ds. 



e no . 

Questions 




What’s all this Timer stuff? Can’t I 


just use a Java thread to close the door? 




Why did you make the timer 


variable final? 


Sure, there's nothing wrong with 
using a Thread to close the dog door. In 
fact, that’s all the Timer class does: kick 
off a background Thread. But the Timer 
class makes running a task in the future 
easy, so it seemed like a good choice for the 
Remote class. 


A: Because we need to call its 
cancel () method in the TimerTask 
anonymous class. If you need to access 
variables in your anonymous class from 
the enclosing class (that’s Remote in this 
case), those variables must be final. And, 
really, just because it makes things work. 


Why are you calling cancel()? 
Won’t the timer quit automatically after 
running the TimerTask? 


It will, but it turns out that most 
JVMs take forever before they garbage 
collect the Timer. That ends up hanging 
the program, and your code will run for 
hours before it actually quits gracefully. 
That’s no good, but calling cancel () 
manually takes care of the problem. 
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gathering requirements 


Wc need a hew simulator! 

Our old simulator isn’t that useful anymore... it assumes Todd and Gina are 
closing the door manually, and not letting the timer do its work. Let’s update 
our simulator to make it work with the updated Remote class:t 



DogDoorSimulator.java 


public class DogDoorSimulator { 


This is 七 he same 
ds \ y \ ou\r cav-|ic\r 


public static void main(String[] args) { 

DogDoor door = new DogDoor(); 

Remote remote = new Remote(door); 


vc\rsior>, but 
pv-css'mj -the - 

bu-fc-fcoh v/ill ope 灼 

"the doov- a^d 
stairt a tirwcv- -to 
匕 lose ihc doov. 


S'mtc doov’s 

or\ d twev*, hdo 

V^as d 

-time *to 
msidie behove 
doov doses. 今 … a 
doesn’t -to 
the door b> 
let f '»do batk m. 


System. out. print In (''Fido barks to go outside •…〃 ）； 
remote.pressButton (); 


System. out. print In (''\nFido has gone outside 

remote .-prooGButton () 

System. out. print In (''\nFido ^ s all done •••〃）； 

remote.pressDutton ( ) 十 

System. out. print In (''\nFido f s back inside. •• 
remote .prcasDutton ()-; 

ahothc\r spot whev-e we 
get \rid o-p some dodc... 
door doses au-tomati^lly. 


// 


參 •參 


); 


七 k MW irupv-ovcd dog 
doov ， doesr /七 heed 
■to p\rcss a but-toh -to dose 
"the doo\r. That will h 外 peh 

au-toma-ti^lly how. 


You lost me on that timer code. 
What’s going on there again? 

A! That’s OK." you don’t need to 
get too hung up on Java here. The point 
is that our use case helped us write good 
requirements, and our requirements made 
it easy to figure out how to write a working 
dog door. That’s a lot more important than 
how—or even in what language—you write 
the dog door code. 


So the new simulator tests out the 
main path we figured out, right? 

A: That’s right. Flip back to page 78 
and review what the dog door does... that’s 
what the new DogDoorSimulator tests 
out. We want to make sure that Todd and 
Gina’s new door works just like they want 
it to. 


Why aren’t we testing out that 
alternate path we found? 

A! That’s a very good question. Let’s 
test this version of the door, and then we’ll 
talk more about that... 
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does it work? 


Test drive, version 10 

It’s time to see if all our hard work is going to pay off. Let’s 
test out the new and improved dog door. 


o Compile all your Java source code into classes. 


javad * java 


DogDoor.java 



DogDoor.class 


Remote.class 


Remote.java 


DogDoorSimulator.java 


DogDoorSimulator.class 



% j |rSimulator 

Fido go outside 


參參 


❺ Run the code! 


File Edit Window Help InAndOut 


% java DogDoorSimulator 
Fido barks to go outside... 

Pressing the remote control button... 
The dog door opens. 


Fido has gone outside. 
Fido A s all done... 

Fido r s back inside... 


e 

.S! 


(cvj seconds 
? ass bcW ⑼ 
i\\t doov- o ⑼… 




Window Help TimelsAThief 


ssing the remote control button 

|| do ^Tw|l s 


• whch it closes. 


F o has gone outside... 

o r s all done... 

Fido r s back inside... 

The dog door closes. 


84 Chapter 2 





















gathering requirements 


It works! Uf s go show Todd and 


Your 

system 
must 
work in 
tke real 
worlct... 


But I don’t think were ready to 
show Todd and Gina yet... what about that 
alternate path, when Fido stays outside 
and the door closes behind him? 


Good catch … we need to 
test alternate paths as 
well as the main path. 

Wouldn’t it be great if things worked just 
like you expected them to every time? 

Of course, in the real world, that almost 
never happens. Before we can show the 
new door off to Todd and Gina, let’s take 
a little extra time to make sure the door 
works when Fido doesn’t come right back 
inside after doing his business. 


0 




… so plan 
and test 
for wnen 


tilings go 



「雜以- 1 

How would you change the DogDoorSimulator 
class to test for Fido staying outside longer? 

- 

Can you come up with at least one more alternate 
path for Todd and Gina’s dog door? Write out the 
use case and update the requirements list for your 
new alternate path, too. 
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alternate paths 


Reviewing the alternate path 

Let’s make sure we understand exactly what happens on the 
alternate path, and then we can update DogDoorSimulator 
to test the new path out. Here’s the original main path diagram 
from page 68, along with the alternate path we figured out 
and added to our use case: 
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gathering requirements 


rtcvcs YiV^cv-c -tv^c 
伽於 ate ^ 

starts... ^°ov ； 

sWts viWilc r»do 
sfell ouWc. 



^Crhc^bcir, -this is 

f h ^02Sic P3ih 
h P —• 


th 




Fido does his business 


( 6 * 2 ) Fido barks to be let back inside. 

s 7 sW aWcady 
V^a^dlcd alt ok 

bese tWmy … 心七 

of 咖 s 

© Todd or Gina hears 
Fido barking (again) 



Todd or Gina presses 
the button on the 
remote control 





O 


Q 



The dog door opens (again) 
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testing the alternate path 


^ iV Code Magnets 




It’s time to update the simulator, but this time it's your job 
to actually write some code. Below is what we have so far for 
DogDoorSimulator. 

Your job is to match the code magnets at the bottom of the page 
to where they belong in the simulator. If you get stuck, check the diagram on 
the last page to see what’s going on at each step of the way. Oh, and there’s 
a twist... all the magents for periods, semicolons, and parentheses fell off the 
fridge, so you’ll have to add those wherever they’re needed, too. 

public class DogDoorSimulator { 

public static void main(String[] args) { 

DogDoor door = new DogDoor(); 

Remote remote = new Remote(door); 


be 咖 s. 

Thread.currentThread(). 


^ - 

( 10000 ); 


catch ( 工 nterruptedException e) { } 



DogDoorSimulator.java 


Here s System. out. print In (''\nFido has gone outside •••"); 

al*tcv-y\a*tc System. out. print In (''\nFido f s all done..."); 


% wah “k p 哼如、 


System. out. print In (''\nFido f s back inside. ••〃）； 





I System.out.printIn 


Rv.qtRlTUod 

~b • pr int 丄 n 




)ressButto 


t+cve avc the methods h> 
the v-cmo-tc dohtvol. 


use 


—h ■ LB,., 



1 System.out.printIn 

J 

- -- 1 



rteve avc 


一乎 

'Fido scratches at the door. 

••. but h e，s stuck 


remote 




waitEoji, 


remote 


AnF 1 




■barking... 


嗯 c avc ^c-tV^ods 
tall orv a 
Java thread. 


88 Chapter 2 


but he Is stuck inside! 


side! M .so Todd grabs the remote control. 
































































































































gathering requirements 


Test drive, version l\ 

Make the changes to your copy of DogDoorSimulator. java, 
and then recompile your test class. Now you’re ready to test out the 
alternate path of your use case: 



File Edit Window Help InUkeFlynn 


% java DogDoorSimulator 
Fido barks to go outside... 

Pressing the remote control button. # . 
The dog door opens. |Q 

Fido has gone outside. . . ' 

Fido's all done... 1 


Uc doov o ? ^s, 

^ocs to 

do W»s Ws^css. 


Bu 七 Fido siavts 

dog door dloscs v/Kilc 
Kc ； s still ou*tsidc. 


Fido bavks -to gc-t badk 
ihsidc, 3hd uses hcv- 
^oic doh^tvol... 





File Edit Window Help ThereAndBackAgain 


% java DogDoorSimulator 
Fido barks to go outside... 
Pressing the remote control butl 
The dog door opens. 

Fido has gone outside... 

Fido f s all done... 

The dog door closes. 

•••but he's stuck outside! 


Fido starts barking... 

...so Gina grabs the remote control. 
Pressing the remote control button.. 
The dog door opens. 

Fido^ s back inside.•• 

The dog door closes. 


Edit I Window Help TheOutsiders 


DogDoorSimulator 
barks to go outside... 
ing the remote control button.. 
og door opens. 

Fido has gone outside... 

Fido f s all done... 

The dog door closes. 

•••but he's stuck outside! 

Fido starts barking... 

...so Gina grabs the remote control. 
Pressing the remote control button.. 
dog door opens. 

s back inside... 



… 3hd Pido 

V"ctu\rh "to aiv- 
^Ohdi-tiohihJ. 


c wM 


4 y . : 0 

6\oses 

Wy o 办 dc . 
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completing the simulator 



Code Magnets 
Solution 


Here’s what we did to complete the simulator. Make sure you got 
the same answers that we did. 


public class DogDoorSimulator { 

public static void main(String[] args) 
DogDoor door = new DogDoor (); 

Remote remote = new Remote(door); 



DogDoorSimulator.java 



V^u should have wv-i-fc-tch 
,h P^iocis, scrhidolohs, 

如 d pairch-thcscs as you 
needed therh. 


System.ou 


one outside 


n 


System. out. print In (''\nFido A s all done •••〃）； 


try { 

Thread.currentThread(). 


sleep 


( 10000 ); 


catch ( 工 nterruptedExceptiLon e) 



You 6ould V^avc 

about Todd 

s do 吶 

^ oUk 化代 . 


System.ou 


k inside 


90 Chapter 2 












































































gathering requirements 


delivering the hew dog door 

Good use cases, requirements, main paths, alternate paths, and a 
working simulator; we’re definitely on the road to great software. 
Let’s take the new dog door to Todd and Gina. 



I I I \ji\y\yi i v/ur'S! V\/0 
don’t have to get out of bed to let 
Fido out anymore, and the door 
closes on its own. Life is good! 

—A. ‘ ^■ 


Todd ± ^ avc 



pido’s "msidc) a^d *tV^c 
y-abbi'ts) y/oodfi-iiutks, 3\r\d 

m'ide av-c outside- 



TWis y/ds e%a6-bly ouUomc >/c 
v/ev-e -fov- v/ay oy \ ㈣ c 

fcO. lAA^a 七 a ^ood 

vc^uiv'cw'C^'ts make ， huh? 


Working app, happy customers 

Not only did we turn Todd and Gina into satisfied 
customers, we made sure their door worked when Fido did 
something they didn’t expect — like stay outside playing. 
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when things go right 



Use Cases Bxyosedi 

This week’s interview: 

Getting to Know the Happy Path 


Head First: Hello there. Main Path. 


Happy Path： Actually, I prefer to be called “Happy Path.” I know a lot of books refer to me as “Main 
Path,” but I find lots more people remember who I am when I go by “Happy Path.” 

Head First: Oh, I apologize. Well, in any case, it’s great to have you with us today, Happy Path, and you’re 
right on time, too. 

Happy Path： Thanks... I’m always on time, that’s really important to me. 

HeadFirst： Is that right? You’re never late? 

Happy Path： Nope, not a single time. I never miss an appointment, either. I never make a mistake, nothing 
ever goes unexpectedly... you can really count on me to come through just like you want, every time. 

HeadFirst： 丁 hat’s quite a statement to make. 

Happy Path： Well, it’s just part of who I am. 

HeadFirst： And that’s how you got your name? You make people happy by always being on time and never 
making a mistake? 

Happy Path： No, but that’s close. They call me “Happy Path” because when you’re hanging out with me, 
everything goes just as you’d hope. Nothing ever goes wrong when the “Happy Path” is at the wheel. 

HeadFirst： I have to admit, I’m still a bit amazed that nothing ever goes wrong around you. Are you sure 
you’re living in the real world? 

Happy Path： Well, don’t get me wrong... things definitely go wrong in the real world. But when that 
happens, I just hand things off to my buddy，Alternate Path. 

HeadFirst： Oh, I think I see now... so things can go wrong, but that’s Alternate Path’s job to handle. 

Happy Path： Yeah, pretty much. But I don’t worry too much about that. My job is to take care of things 
when the sun is shining and things are going just like people expect. 

HeadFirst： Wow, that must be really satisfying. 


Happy Path： Well, most of the time it is. But things do tend to go wrong a lot. It seems like hardly anyone 
sticks with me from start to finish. Alternate Path usually gets involved at some point, but we get along well, so 
it’s no big deal. 

HeacFirst: Do you ever feel like Alternate Path is butting in? I could imagine some tension there... 

Happy Path： No, not at all. I mean, we’re all after the same thing: getting the customer to their goal, and 
making sure they’re satisfied. And once we’re defined well, actually coding an application is a lot simpler. 

HeadFirst: Well, you heard it here folks. Next week, we’ll try and catch up with Alternate Path, and get her 
side of the story. Until then, try and stay on the Happy Path, but remember to plan for problems! 
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gathering requirements 




命 

m 命 


Below on the left are some of the new terms you’ve learned in this chapter. On the right 
are descriptions of what those terms mean and how they’re used. Your job is to match 
the term on the left with that term’s purpose on the right. 


Bxtmdi 

cm 


_Vaii^ 

_CPHpltlpH 



Kicks oil tke list oi steps ctescritect in a 
use case. Witkout tkis, a use case never gets 
going. 

Sometking a system neects to do to te a 
success. 


Lets you know wken a use case is finiskeci. 
Witkout tkis, use cases can go on iorever. 


Helps you gatker good recjuirements. Tells a 
story aLout wkat a system ctoes. 


Wkat a system does wken eyerytking is 
going riglit. Tkis is usually wkat customers 
ctescrite wken tkeyVe talking about tke 
system. 



Tkis is always tke first step in tke use case. 

Witkout tkis, a use case isn’t wortk anytkingf 
to anyone. Use cases witkout tkis always fail. 


oVv" f av-b <Jc some -bev-ms OY\ 

Ic-ft V^avc missrnj. Vou VC jot io use 

dcMor^s or. ^aicM a 


you are here ► 


93 









I have a purpose 



E 從 RciSe 

、 *1 • 

^PLvtlPHS 


+WM 



命 


命 


Below on the left are some of the new terms you’ve learned in this chapter. On the right 
are descriptions of what those terms mean, and how they’re used. Your job is to match 
the term on the left with what that term’s purpose is on the right. 


ExtdRHai 




Wsc C 撕 


Condi 七 ion 


曲 i 


Clear 


Siof CpHpi^OH 


Ma\r\ ?atH 







Kicks off tke list of steps JescriteJ in a 
use case. Witkout tkis, a use case never gets 
going. 

Sometking ； a system kas to Jo to te a success. 

Lets you know wken a use case is iiniskect. 
Witkout tkis, use cases can go on forever. 


Helps you gfatker gfood require me nts. Tells a 
story about kow a system works. 


How a system works wken every tiling ； is 
going ； rigfkt. Tkis is usually wkat customers 
Jescrite wken tkeyVe talking about tke 
system. 


Tkis is always tke first step in tke use case. 

Witkout tkis, a use case isn’t wortk anytking ； 
to anyone. Use cases witkout tkis always fail. 
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gathering requirements 



arpen your pencil 


Time to write some more use cases. 

Below are three more potential customers that are interested in 
Doug’s Dog Doors. For each customer, your job is to write a use 
case to solve the customer’s problem. 


5 從 



o 


Bitsie is constantly nudging 
open our back door, or nosing open the 
kitchen bay windows. I want a system that 
locks my dog door and windows behind 
me every time I enter a code, so Bitsie 

can’t get out. 






Bruce is constantly barking, so 
I never know if he really wants 
out or not. Can you build a door 
that opens up when he scratches it 

with his paws? 


Tex is constantly 
tracking mud inside the house. I 
want a dog door that automatically 
closes every time he goes outside, and 
stays closed until I press a button to let 
him back in. 





r 





Bv*udc 


Aiders on pa^e 96. 
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use case bonanza 




arpen your pencil 


answers 


Time to write some more use cases! 

You’ve seen the customers; now let’s look at the use cases. Here is 
how we wrote our use cases for the dog-loving folks on page 95. 
See if your use cases look anything like ours. 


Bitsie is constantly nudging 
open our back door, or nosing open the 
kitchen bay windows. I want a system that 
locks my dog door and windows behind 
me every time I enter a code, so Bitsie 

caiVt get out. 



s use Case is 
just two s-teps ： she 
c ^\rs a Code, 3hd 

厂 "the dog dooir dhd 
^ 七 k w'mdows lod 



Kristen and gitsie's Pog Poor 


1. Kristew enters a code on a keypad. 

2. The dog door and all the windows 
in the house lock. 


tw«s *»S a 
do(\ doov, Bvts'e ae-W'7 
V^asriS ^ 


Tex is constantly tracking 
mud inside the house. I want a 
dog door that automatically closes 
every time he goes outside, and stays 
closed until I press a button to let 
him back in. 


O 


vUA request oul to be very 

simildv* *to v/ha 七 Todd 
y/a^ted. part ^ood 

youve already W»l 七 sW.lav 

{jo y/Vidi d tus*bomcr warrts. 


OoVxyx 
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gathering requirements 


Bruce is constantly barking, so 
I never know if he really wants 
out or not. Can you build a door 
that opens up when he scratches it 

with his paws? 



vcall 7 如办於 t 

laid out ^ 

>wV\at rtoll'/ 
but 70U should 
V^ave Vt 

out ^ova 

tW# tWr— 

V.o>w V^cv s'/stem 
Will be used. 


Holly and truce's Poq Poor 

1. Pruce scratches at the dog door. 

2. The dog door opens. 

$. Pruce goes outside. 

4. The dog door closes automatically. 

4 . Prucc does his business. 

5 . Prucc scratches at the door again. 

6. The dog door opens up again. 

7 Pruce comes back inside. 

8. The door closes automatically. 


o 


r 


WoW't 


Bv*u 匕 e 


redlly need m-fovmatioy\ 
*to y/v'i*tc *t^is use tase." looks 
like v/c r^ccd *to ask JoU some 


Evch though Johh said Tex 
usually gets muddy, he docs^i 
to get muddy... so ihai J s 
代 ally 釙 alic^ic path. 


► 


John and Tex's Pog Poor 

X(Somehow) the dog door 

- 71 

4. Tex does his business. 

opens. 

4.1 Tex gets muddy 

2. Tex goes outside. 

4.2 John cleans Tex up 

$. The dog door closes 

5 . John presses a button. 

6. The dog door opens. 

1 Tex comes back inside. 

S. The door closes automatically. 
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the three components of a use case 



s 


More Use Case Magnet 

Remember the three parts of a use case? It’s time to put what 
you’ve learned into action. On these pages, you’ll find several 
use cases; your job is to match the use case magnets on the 
bottom of the page to the correct parts of each use case. 



dah v-cvicw all 
these by -Plippi h g 
-to page 7 午 . 


Holly and truce's i?oq Poor 

Pruce scratches at the dog door to be let out. 

The dog door automatically opens, and Pruce 
goes outside. The dog door closes after a preset 
time. Pruce goes to the bathroom, and then 
scratches at the door again. The dog door opens 
automatically, awd Pruce returns inside. The dog 
door then closes automatically. 

If Pruce scratches at the door but stays inside 
(or stays outside), he caw scratch at the d< 

again to re-opew it from inside or outside| Kristew awd gitsie's l?oq Vnnr^ 

1. Kristen enters a code on a keypad. 

2. the dog door and all the windows 
in the house lock. 


\/ou should be able *to -follow/ - 
•bV^csc al*bcv-r\a*tc use ^asc 
-fov-ma*bs y/rbhou 七 muA "trouble, 
you yt doy\*Pusccl> ou*t 

I -foV" *biiC stoop ov\ 
use CBst 



0 *(* d use 
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(7^ This maghet ihdi^a-tes 
■the sia\ri dohdi-tioh Ioy 
3 use Use. 










































gathering requirements 


Main Path 

1. Tex goes outside. 

2. The dog door closes automatically. 

3. Tex does his business. 

4. John presses a button. 

5. The dog door opens. 

6 Tex comes back inside. 

1 The door closes automatically. 

Extensions 
3.\ Tex gets muddy. 

3,2 John cleans Tex up. 



rido hcv-c 
v-cpv-csc^*b 

the 

mi-tiatov- o-f a 
use tBst, 
kicks o^-f. 




johw awd Tex's Poq Poor 

Primary Actor: Tex 

Secondary Actor: John 

Preconditions: The dog 
door is open for Tex to go 
outside. 

&oal: Tex uses the bathroom 
and comes back inside, 
without getting mud 
inside the house. 


Use *b^*»s 

-fo\T *bv^ 

s*bop ^oy\dit»or\ 

J< a use tasc. 

Hoy/ do you 
kir\oy/ 

■bKc use cast is 
-(•misled? 


t 




STOP 

ISTOP 


dol 杳 i § sela^suy ▲ 
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use case magnets solutions 



Use Case Magnets Solutions 

Remember the three parts of a use case? It’s time to put what 
you’ve learned into action. On these pages, you’ll find several 
use cases (in different formats, no less!); your job is to match the 
use case magnets on the bottom of the page up to the correct 
parts of each use case. 



llv awd truce's i?oq Poor 


ratches at the dog door to be let out. 
door automatically opens, and Pruce 
goes outside. The dog door closes after a preset 
time. Pruce goes to the bathroom, and then 
scratches at the door again. The dog door opens 
iUtomatically, and Pruce returns inside. The dog 
jorthew closes automatically. 

Jf Pruce scratches at the door but stays inside 
stays outside), he can scratch at the door 
again to re - open it, from inside or outside. 


Look tloscly -Vov 
m *tWis 
use tascs ； its usually ^i£t 

W\t las*t scv\*tc^c ^ 
av-c ^ al*tcv-y\a-tc 





External Initiator 


uce can get 
outtide to use the 
iroom without 
Holly having to open 
and close the dog door 
(or even listen for 
Pruce to bark) 




/ 


The dlcav value a use 
dasc—m most -fo\rrwa*U— 
is^*t s*ta*tcd m the use 
CBSt, so you’ll Y\ttd *to 
-Pi^uv-c i*t ou*t oy\ youv ov/^. 






wd 択 tsie's l?oq Poor 


itsie can't get outside without 
isten letting her out. 
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TV »s 

almost aU/ays 七 ^ last 
s*tc^ *tV^c use tase. 



Kristen enters a code on a keypad. 

tpie dog door and all the 
iw the house lock. 





























































































gathering requirements 


|y\ 七 Wis use tasc 

*t^c c%tcv-y^al 
•mrtia*tov* »s al>w3ys *t^c 
pv-'imav-y at*tov. 


a 


imC 

use tasc »s 

—frtV/ state 
you've 7 OVA， 
c\t^c 


4ohyt and Tex's Pclyoir 

Primary Actor: Te)(] 

Secondary Actor: 

Preconditions: The dog 
door is open for Tex to go 
outside. 

&oal: Tex uses the bathroom 
and comes back inside. 


Main Path 

1. Tex goes outside. 

2. The dog door clo; 

3. Tex does his business. 

4. John presses a button. 

5. The dog door opens. 


imatically. 


J 

—— ^ 

jut getting mud 

6 Tex comes back inside. 

1 

Beside 

tthc house. 

1 The door closes automatically. 

1 

OOdl 



Extensions 1 


STOP 





3\ Tex gets muddy. 

3.2 John cleans Tex up. 


卜 0 t ok ‘ he 
，asl ihc 

CX tChSlOhS. 
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the power of use cases 



arpen your pencil 


What’s the real power of use cases? 


You’ve already seen how use cases help you build a complete requirements list. Below are 
several more use cases to check out. Your job is to figure out if the requirements list next 
to each use case covers everything, or if you need to add in additional requirements. 


jCristcw awd gjtsjcj Pog Poor 

Use Case 

1. Kristew enters a code on a keypad. 

2. The dog door and all the windows 
mthe house lock. 


Kristen and ^itsie's l?oq |?oor^ 
Requirements List 

H keypad most accept a 4 - digit 
code. 

么 Hie keypad wust be able to lock the 
dog door: 


lis*t -fov ^\ris*tc^s do^ 
door. |s 

ov based 

oy\ 'tKc use d3sc? 1*(* 
so, y/v»*tc m c%*tv"3 
you 七 iVmk 

doov r\ccds *to 


Rcw'CW'locv* ^v*is*tcy> 
dy\d 
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gathering requirements 


Hollv and truce's Pog Poor 

Use Case 

1. Pruce scratches at the dog door. 

2. The dog door opens. 

$. Pruce goes outside. 

4. The dog door closes automatically. 

4. ?ruce does his business. 

5. Pruce scratches at the door again. 

6. The dog door opens up again. 

7 Pruce comes back inside. 

8. The door closes automatically. 


Holly is Psyched 
abou-t li+c wi-th 
>^cw dog doov-. H 
j us 七 h ^cds -to woirk ； 
shes all sc-t/ 



Holly and truce's ^oa l?oor^ 
Requirements List 

1. The dog door must detect scratching 
from a dog. 

2. The door should be able to open on a 
command (from ^1). 


|s 七 
\{!s uf *bo Y ou 
make su^rc Holly ,s a 

satisfied tusW 吖 . 


► Answers on pa 贫 e 104 
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from use cases to requirements 


Sharpen your pencil 


answers 


What’s the real power of use cases? 


In each situation below, the use case describes how the dog door should work-but the 
requirements aren’t complete. Here are the things we saw that were missing from the 
requirement list, based on the ever-helpful use case. 


Kristeyi ayid gitsie's Pog Poor 

Use Case 

1. Kristew enters a code on a keypad. 

2. The dog door and all the windows 
mthe house lock. 


This or\t v/as a little Uiev... 
-tKc use dase docs^*t mcir>tioir> 
about Brtsie 

badk \y\, so v-cally use dasc 
ar>d vc^u'ivcmc^'U lis*t av*c 
*mdomplc*tc- >would^*t 

be -too i^afpy she dould^*t 
uy>lodk cvcv-y*thm5> v/ould sKc? 



Kristew awd gitsie^s l?oq l?oor 
Requirements List 

1. TTie keypad must accept a 4-digit 
code. 

么 TTie keypad wust be able to lock the 
dog door and all the windows. 

多 • rjie keypad must be able touRIock 


the dog door and all the windows 
iw the house. 


This 

is kor^pld. 
^ ,s ich y/^is 

able {o 

lo6k ihc doo^s 
windows. 


Be davc*ful| 6jood use casts make *fo\r (\ood v-c<\ui\rcmc^is, but a 
bad-ov- mdom^lc-tc-usc tasc cav\ v-csuli m BAP 
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gathering requirements 


Holly ayid truce's Poq Poor 

Use Case 

1. Pruce scratches at the dog door. 

2. The dog door opens. 

$. Pruce goes outside. 

4. The dog door closes automatically. 

4. 孩 ruce does his business. 

5. Pruce scratches at the door again. 

6. The dog door opens up again. 

7 Pruce comes back inside. 

8. The door closes automatically. 



Holly and ^n/ce's l?og l?oor_ 
Requirements List 

1. The dog door must detect scratching 
from a dog. 

2. The door should be able to open on a 
command (from ^1). 

3. The dog door should close 
automatically. 


This ••〜“釓. 


d 
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ooa&d toolbox 



Tools for your 00A 备 P Toolbox 

OOA&D is all about writing great software, and 
you can’t do that without making sure your apps do 
exactly what customers want them to. 


In this chapter, you learned several tools for making 
sure your customers are smiling when you show them the 
systems you’ve built. Here are some key tools to keep handy: 




^ood \rcc\u*«rcmc^-b youV 

Y/o\rks like Y ouV ， 〜如 心亡平己七 . 

Make SUV-C Y ouV " \rc<\u*»\rcmc^-ts dovcv- all 
stc^s *m use tascs (or youv system- 

Use Y ou,r usc ^ascs -to -f rnd ou-t about 
七雜 ^ uS ^° wC，rS 七匕 W Y ou ’ 

y ouV . use tascs Y/ill 'reveal W。—ele 

OV \rc<\u*i\rcmc^ls iKat you m 吵七 

have -bo add y ouV ， s Y s ^ cw ' 


00 Bas^s 


〜 re 〜 
of i he 

, ke y ^ols y ou 

lca ^cd ^boui 


Wc II be 

dddnr\5 lo*ts 
move "bools -to 
-t^ese o 七 hev 

ta-tc^ov-'ics-^ 

•m *tV^c 
Rafters. 


QO P\rm6iple 


s 


BULLET POINTS 

■ Requirements are things your 
system must do to work correctly. 

■ Your initial requirements usually 
come from your customer. 

■ To make sure you have a good 
set of requirements, you should 
develop use cases for your 
system. 

■ Use cases detail exactly what your 
system should do. 

■ A use case has a single goal, but 
can have multiple paths to reach 
that goal. 

■ A good use case has a starting 
and stopping condition, an 
external initiator, and clear value 
to the user. 

■ A use case is simply a story about 
how your system works. 

■ You will have at least one use case 
for each goal that your system 
must accomplish. 

■ After your use cases are complete, 
you can refine and add to your 
requirements. 

■ A requirements list that makes all 
your use cases possible is a good 
set of requirements. 

■ Your system must work in the real 
world, not just when everything 
goes as you expect it to. 

■ When things go wrong, your 
system must have alternate paths 
to reach the system’s goals. 
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來 Readers o( Head Fi\rs*t 
-familiav-... -thats because 


Dcsi^ Patterns will -fmdl -these ^a*tcjov-ics 

* OOAfV m hand. 











gathering requirements 




OOA&D cross 



Across 

今 . Thfi ma> : n path is sometimes caNecf the 

_ poth. 

!?. A u^e cose, must have this (tw& ivords) to 

the uier„ 

8. ftecyu 丨 nemenfs efiiure that your System 
hvorkd_. 

10. In the dog door system, who was the 

t^lisrnu 『 irti1iator> 

IHi U<i%. r^tKe.K fnru< inn n J _ie^pj™ 

^oull 

H WKfji Fjfffl k h#ir* r thft drvg dnnr Ivi^ hit rts 

stop cond 作 Jorv. 

ife. A uOt £a£e if juS 會 q list *f thi ngS 肀 hat a 

fiySTem ___ 

2S. A ytie- cafe teJilf a,_about how a 

system, worki. 

21 . are to under^tarKi when 

they J re ir\ this Icind of kirTqiiaqe. 

22. Gctad ude ca5U mak* for _ 

reQuirements. 

£4. A u^e ca^e hefpj you under stand how q 
< y<tpm will he. _ 

£5. Uaie uiScai help you ^alh^r _ 


Down 

1. A use aise details haw a system _ 

with liters or other ^5tc,m^ r 

Z, When things go right」you ne on this, 

3. L/Sc caifej .arc d dboui - the m _ ■■ yaur 

syst&m. 

(r. Without caSei, yau won't lkr»h¥ if your 

requirements ar*_. 

7, If you Kuv& four Liuals I'n u iyi I cm, you'll 
hnw. rtt J«n^t thi< mnny ii^r rn 

9. SdckJ 3iy£lein3£ work rn the_ _ 

11 FJHfl thi< +rt «tignn 『 會 ] ift ^tnrt nf +hp rf^g 

door system's use case. 

\2. When things go wrong, you end up cn an 
,.,, path. 

15. Fjd* \&ni port of tkk, but his dog door i£ r 
17. This is what you fhauJd do to lha cuSTomer 
to gfl.tha,r an Fnitial : Set of requireme,FitS„ 

19. Haw many uisa are the-* in Todd ord 

Sifio's dog door? 

SO. F?do wad chba^ir^i these wKcn he got Stuck 
^3. A roqu^nsm^nS d^LumenlS thi^ n^ny need^, 
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exercise solutions 



Code Magnets Solutions 

The DogDoor class is done, so all you need now is to write a class for 
the remote control. We’ve started this class below, but it’s your job to 
finish things up. Using the code magnets at the bottom of the page, 
complete the code for the Remote class. 

Be careful... you may not need all the magnets. 


public class Remote 


private I DogDoor 


door 


public Remote ( 

this • door = dIHH 


1 door 

) 



public void pressButton () { 

System, (''Pressing the remote control button 

isOpen I ( ) ) { 

m 



rtcvcs Neat’s IdW 



108 


Chapter 2 
















































































gathering requirements 




E 站 RciSe 

..*1 • 

SpLvtlPHS 
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3 requirements change 

/ Love You ， You’re Perfect." 

Now Change 



Think you’ve got just what the customer wanted? 

Not SO fast... So you’ve talked to your customer, gathered 
requirements, written out your use cases, and delivered a killer application. 
It’s time for a nice relaxing cocktail, right? Right... until your customer 
decides that they really wanted something different than what they told 
you. They love what you’ve done, really, but it’s not quite good enough 
anymore. In the real world, requirements are always changing, and it’s 
up to you to roll with these changes and keep your customer satisfied. 


this is a new chapter 
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welcome to paradise 


YouYc a hero! 


A nice pina colada to sip on, the sun shining down on you, a roll of 
hundred dollar bills stuffed into your swim trunks... this is the life of a 
programmer who’s just made Doug’s Dog Doors a successful venture. The 
door you built for Todd and Gina was a huge success, and now Doug’s 
selling it to customers all across the world. 

pour’s 

some serous Wks 
^\i\\ 70UV code 


Put thew came a phone call 


庸 tt 


o 


Listen, our dog doors 
been working great, but wed 
like you to come work on it 
some more... 



Tired of cleaning up your dog’s mistakes? 

fie—t| Someone else to let your dog outside? 

ioors that stick when you open them 


bug’s Dog Doors 


★ Professionally 
installed by our 
door experts. 

★ Patented 
all-steel 
construction. 

★ Choose your own 
custom colors 
and imprints. 

★ Custom-cut door 
for your dog. 



Call Doug today at \ — 


Todd 知 a, 


You ： Oh, has something gone wrong? 

Todd and Gina ： No, not at all. The door works just like you said 
it would. 

You ： But there must be a problem, right? Is the door not closing 
quickly enough? Is the button on the remote not functioning? 

Todd and Gina ： No, really … it’s working just as well as the day 
you installed it and showed everything to us. 

You ： Is Fido not barking to be let out anymore? Oh, have you 
checked the batteries in the remote? 

Todd and Gina ： No, we swear, the door is great. We just have a 
few ideas about some changes we’d like you to make... 

You ： But if everything is working, then what’s the problem? 
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requirements change 


Were both tired of having 
to listen for Fido all the time. 
Sometimes, we don’t even hear him 
barking, and he pees inside. 


O 



And were 
constantly losing that 
remote, or leaving it in 
another room. I'm tired of 
having to push a button to 
open the door. 


O 


Todd and Nina's Poq Poor: version 2.( 

What the Poor (Currently) Poes 

1. Fido barks to be let out. 

2. Todd or (rim hears Fido barking. 

炙 Todd or (r\m presses the button ow the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1. The door shuts automatically. 

6.2. Fido barks to be let back inside. 

6 •炙 Todd or &ma hears Fido barking (again). 

6.4. Todd or friwa presses the button ov\ the 
remote control. 

6.5. The dog door opens (again). 

1 Fido goes back inside. 


0 


O 


0 


What if the dog door opened 
automatically when Fido barked at it? Then, 
we wouldtVt have to do anything to let him 
outside! We both talked it over, and we 
think this is a GREAT idea! 



you are here ► 
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the customer is right 


Pack to the drawing board 


Time to get working on fixing up Todd and Gina’s dog 
door again. We need to figure out a way to open the 
door whenever Fido barks. Let’s start out by... 


Wait a minute... this totally 
sucks! We already built them a 
working door, and they said it was 
fine. And now, just because they had 
some new idea, we have to make more 
changes to the door? 


The customer is always right 

Even when requirements change, 
you’ve got to be ready to update your 
application and make sure it works 
like your customers expect. When your 
customer has a new need, it’s up to you 
to change your applications to meet 
those new needs. 


pou^ loves I 七 
s'mtc 

Todd -fov- 

i\\t 州 ake. 


0 



「雜口 ，- 

You’ve just discovered the one constant in software 
analysis and design. What do you think that constant is? 
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The owe cowstawt m software analysis and design* 


requirements change 


Okay ， what’s the one thing you can always count on in writing software? 

No matter where you work, what you’re building, or what language you are programming in, what’s 
the one true constant that will always be with you? 

dmm 

(use a mirror to see the answer) 


No matter how well you design an application, over time the application 
will always grow and change. You’ll discover new solutions to problems, 
programming languages will evolve, or your friendly customers will come up 
with crazy new requirements that force you to “fix” working applications. 


f^^rpen your pencil 


Requirements change all the time... sometimes in 
the middle of a project, and sometimes when you 
think everything is complete. Write down some 
reasons that the requirements might change in 
the applications you currently are working on. 


My dus-bomev dedidedi 七 hat 七 liey 七 he applidation -to wovk di-f-fcv-crvtly- 


My boss my application would be bettev- as a web applidation 七 ban a dcsk*to^> app. 


Recjuirements 
always ckange> 
II you’ve got 
good use cases ， 
tkougfli, you can 
usually ckange 
your software 
cjuickly to adjust 
to tkose new 
reejuirements. 


决 |*f you’ve read Head Pivs 七 Dcsi^ -this pajc look a bi 七 -familiav-. 

They did a ^ood job dcs^v-ibmg wc decided *to \us*t v-ip -theiv- 

ideas ； d^d jus*t CttANq£ a -few *tiVi 呼 hcv-c a^d Thanks, oc{\\ a^d ^c\t\ 
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add an alternate path 



E 站 RciSd 


Add bark recognition to Todd and Gina’s dog door. 

Update the diagram, and add an alternate path where Fido barks, Doug’s 
new bark recognizer hears Fido, and the dog door automatically opens. The 
remote control should still work, too, so don’t remove anything from the 
diagram; just add another path where Fido’s barking opens the door. 
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requirements change 



© Todd or Gina hears 
Fido barking (again) 



Todd or Gina presses 
the button on the 
remote control 



O 


o 



The dog door opens (again) 


you are here 


117 









meeting fido’s needs 



E^RciSe 

■- •» • 

^PLvtlPHS 


Doug’s invented hardware to recognize barks, but it’s up to you to 
figure out how to use his new hardware in the dog door system. 

Here’s how we solved Todd and Gina’s problem, and implemented their 
bark-recognizing dog door. See if you made similar additions to the diagram. 




Gina, open the dog 
door... Fido won’t 
quit barking! 


® Todd or Gina hears Fido barking 
⑧ Todd or Gina presses the button on 


the remote control. 


Fido barks to be let out 


(^)The bark recognizer 
“hears” a bark 


W!c y\ccd *to add a 

ka^rk 

*to 七 he 

do^ doov-. 


Most diaya^ 

needed o^/ ^csc *Uo 


(^^The bark recognizer 
A sends a request to the 


door to open 


④ The dog door opens 
® Fido goes outside 


加孙 alW^atc 




® The door shuts automatically 
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requirements change 



O 


© Fido barks to be let back inside. 


© Fido does his business 


Smdc steps 
av-c alv-cady 
al*tcv*ir\5*tc pa 七 h ， 
v/e v\ttd *Uo sub 
s*tcf y\uw»bcv"S. 



The bark recognizer 
hears” a bark (again) 


The bark recognizer 
sends a request to the 
door to open 



Again with the 
barking! Someone let 
Fido back inside. 


Todd or Gina hears 
Fido barking (again) 



Todd or Gina presses 
the button on the 
remote control 


The dog door opens (again) 


O 


Q 
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which path do i follow? 




But now my use case is totally 
confusing. All these alternate 
paths make it hard to tell what in the 
world is going on! 


Optional Path? 
Alternate Path? 
Who caw tell? 


Thc\rc 

3\rc how * 

steps -Pov- 
both it=Z 

amd 养 4 


七 he 
al 七 cma 七 c 
s-bc^s 
y\OY/ V^avc 
al*tcv-y\a*tc 

steps. 


Todd and Nina's Poq Poor, version 2.1 

What the Poor Poes 

1. Fido barks to be let out. 

2. Todd or &ma hears Fido barking. 

2.1. The bark recognizer "hears" a bark. 

Todd or friwa presses the button ow the remote control. 

3.1. The bark recognizer se^ds a request to the door to 
ope". 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1. The door shuts automatically. 

6.2. Fido barks to be let back inside. 

6 • 多 . Todd or friwa hears Fido barking (again). ^ 

6.3.1. The bark recognizer "hears" a bark (agaiw). 

6.4. Todd or (j\m presses the button ow the remote 
control. 

6.4.1. The bark recognizer se^ds a request to the door 
to open. 

6.5. The dog door opens (again). 

1 Fido goes back inside. 

S. The door shuts automatically. 


o 


o 





These a 代 lasted as sub- 

s*tc^s, ku*t ^ally a，rC 
^vovidi^ ^ c*tclY 
出扛⑽七？必七 Wou 吵 


七 use 


TV^csc sub - 心 ? s 
ov-ovidc addiWal 
set stc\>s 
be … 

… bu 七 sub—s*tcps 

avc vcally a di^evey>i 
v/ay *to v/ovk 七 Wo— 
*tKc use tasc- 
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requirements change 



I still think this use 
case is confusing. It looks 
like Todd and Gina always hear Fido 
barking, but the bark recognizer only 
hears him sometimes. But thafs not 
what Todd and Gina want... 


Po 7 ou see 

aboi? Todd “气十 V dca 

was 栋 a 七栋 q 如 

1 如 U P«aos fea ㈣ 


\ y \ -t^c use tasc, 
we \rcall 7 v/a^-t -to say 
妊 a 七 tjh^r r or 

£*tcf Z.Uap^s... 




… a 灼 d ei-bhev Step Z 

or Step 31 happens. 


Wtrt, either Step ^>3 

ojr ^> 3.1 happens... 


... av\A e ， 七一 厶今 
ov &今 .1 V ^ a ^ c ^ s . 


Todd and Nina's Poq Pooc version 2.1 

What the Poor Poes 

1. Fido barks to be let out. 

2. Todd or (rim hears Fido barking. 

21 The bark recognizer "hears" a bark. 

3. Todd or friwa presses the button on the remote control. 

3.1. The bark recognizer se^ds a request to the door to 
ope". 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1. The door shuts automatically. 

6.2. Fido barks to be let back inside. 

6 •炙 Todd or (r\m hears Fido barking (agaih). 

6.3.1. The bark recognizer "hears" a bark (agaiw). 

6.4. Todd or &ma presses the button ow the remote 
control. 

6.4.1. The bark recognizer se^ds a request to the door 
to open. 

6.5. The dog door opens (again). 

1 Fido goes back inside. 

S. The door shuts automatically. 


you are here ► 


121 












write it any way you want to 


Use cases have to make sense to you 


If a use case is confusing to you,you can simply rewrite it. There are tons of 
different ways that people write use cases, but the important thing is that 
it makes sense to you, your team, and the people you have to explain it to. 
So let’s rewrite the use case from page 121 so it’s not so confusing. 


。咖 d w 卜 〜 A 

^ thc ^dhi 


|^0>W 

added a label 
•to 七 ell vas 七七 
i\\W steps 
i\\t \t^i a\rc 
par 七。 *tV^c 
w\dnr\ 七 Vv 


Todd and Nina's Poq Poor, version 2.2 

What the Poor Poes 


Main Path 



iVhch theire’s 
oY\\y a s'mjlc sicp, 
well always use 
七 ha 七 s-tep y/hch 
v/c 50 -thvoujh 
七 he use ddsc. 

These suk-s-tefs 

avc op 七， oy>a l... Y ou 
may use -bV^cw, 

\jo\A ha vc 
U. Bu 七 

still OY\ 七，， 
kedduse 七 V^Y do^-b 
v^gla^e steps oy \ 
be mdm pa 七 W 


1. Fido barks to be let out. 

2. Todd or (r\m hears Fido barking. 

炙 Todd or (rim presses the button ow the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 



Alternate Paths 


21 The bark recognizer "hears" a 
bark. 

The bark recognizer sends a 
request to the door to opeh. 


TW»s is a I«UIc tlcaw ： y/c ^ 

use Stc? ^ a ^ A 

七 b 也 ？ 1 也 S 七 c ? 3.1. 


X 6.1. The door shuts automatically. 

6.2. Fido barks to be let back inside. 

6 •炙 Todd or &ma hears Fido barking (again). 


6.4. Todd or friwa presses the button ow the 
remote control. 

6.5. The dog door opens (again). 

1 Fido goes back inside. 

S. The door shuts automatically. 


6.3.1. The bark recognizer "hears" 
a bark (again). 

6.4.1. The bark recognizer sehds a 
r request to the door to opew. 

These sieps o h ^ ^ 

S + c P s 砭 3 扣 cU. 午 . 

Y °\^ ° h, y ^ Ohc sicp {o 

w o\rl< "thlroujli -fch 


^3sc- 




七 Wou 吵 *tK»s use case, Youll 
aly/ay s ⑼ d up a 七 S*tc\> ® oy\ 
*t\ic n\di\v\ pa*tVv 


122 Chapter 3 










requirements change 


If we can really write the use 
case however we want, can we make the 
bark recognizer part of the main path? 
That*s really the path we want to follow 
most of the time, right? 


O 



Excellent idea! 

The main path should be what you want to 
have happen most of the time. Since Todd 
and Gina probably want the bark recognizer 
to handle Fido more than they want to use the 
remote, let’s put those steps on the main path: 



Koy/ S*tc\>S 

七七 mvolvc 七 he 
kav-k rtCoyr\\z^r 
avc ov\ 七 he 
pa-tK, mstcad <^f 
al*tcv-y\a*tc 


Todd and Nina's Poq Pook version 2.3 

What the Poor Poes 


Main Path 

1. Fido barks to be let out. 

2. The bark recognizer "hears" a bark. 

3. The bark recognizer se^ds a request 
to the door to opeh. 

4. The dog door ope^s. 

5. Fido goes outside. 

6. Fido does his business. 

6.1. The door shuts automatically. 

6.2. Fido barks to be let back mside. 

6.3. The bark recognizer "hears" a 
bark (agaih). 

6.4. The bark recognizer sehds a 
request to the door to opeh. 

6.5. The dog door opens (again). 

1 Fido goes back inside. 

S. The door shuts automatically. 




Alternate Paths 

2.1. Todd or &ma hears Fido barking. 

3.\. Todd or &ma presses the button 
oh the remote control. 

1 ? 

~fodd dhd 与 iha v/oh’*t use the 
\rcmo-tc most - the time, so 

the steps >Tt\aied io the 

胂 e bcUc\r as av\ al-tcv-halc path. 

6.3.1. Todd or (rim hears Fido 
barking (agaih). 

6.4.1. Todd or friwa presses the 
button oh the remote control. 
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getting to the goal 

Start to finish: a single scenario 

With all the alternate paths in the new use case, there are lots of 
different ways to get Fido outside to use the bathroom, and then 
back in again. Here’s one particular path through the use case: 


pa*b^ 


七 Wrw 
七 Wis use 

v/'»*bV^ I 


Todd and ^iwa's Poq Poor version 2.3 

What the Poor Poes 

Mam Path Alternate Paths 

1. Fido barks to be let out. - 

2. The bark recognizer "hears" a bark. 2.1. Todd or friwah 

炙 The bark recognizer se^ds a request 
to the door to opeh. 

4. The dog door opens. 

5. Fido goes outside. Well take <>?Wal 

6. Fido does his business. ^ 

6.1. The door shuts automatically. 


3.\. Todd or (rim presses the button 
oh the remote control. 


6.2. Fido barks to be let back inside. 

6.3. The bark recognizer "hears" a 
bark (again). 

6.4. The bark recognizer sehds a 
request to the door to opeh. 

6.5. The dog door opens (again). 

7 Fido goes back inside. 

S. The door shuts automatically. 




6.3.1. Todd or (r\m hears Fido 
barking (again). 

6.4.1. Todd or friwa presses the 
button oh the remote control. 

r 

WlcVc Todd a^d 4 … a 

ha 灼 die door 

oy\ {\\t al*tcv-^a*tc pa 七 iv 


Lets take 
this olltc^hatc 
pa-th, av\d \ti 

|7odd dhd 

hdhdle opehih^ 
the doov* with 
the \rCrwo"tc. 


Follow.^ a^o>ws 3»vcs 70U a 
jrtoU pa 仏 如⑽ 6asc ， 


? 


*tW.s \s tailed a 
TV^cvc a^rc usually several possible 
stc^av-'ios m d s'm^lc use ^ s ^- 


V^’ll always chd 
^ Sicp e, W j^h 
hdo ihside. 
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requirements change 



e no . 

Questions 


I understand the main path of a 
use case, but can you explain what an 
alternate path is again? 


An alternate path is one or more 
steps that a use case has that are optional, 
or provide alternate ways to work through the 
use case. Alternate paths can be additional 
steps added to the main path, or provide 
steps that allow you to get to the goal in a 
totally different way than parts of the main 
path. 




So when Fido goes outside and 
gets stuck, that’s part of an alternate 
path, right? 


Right. In the use case, Steps 6.1, 
6.2, 6.3, 6.4, and 6.5 are an alternate path. 
Those are additional steps that the system 
may go through, and are needed only when 
Fido gets stuck outside. But it’s an alternate 
path because Fido doesn’t always get stuck 
outside—the system could go from Step 6 
directly on to Step 7. 




And we use sub-steps for that, 


like 6.1 and 6.2? 


So what do you call it when you 
have two different paths through part of a 
use case? 


A: Well, that’s actually just another kind 
of alternate path. When Fido barks, there's 
one path that involves Todd and Gina hearing 
Fido and opening the door, and another path 
that involves the bark recognizer hearing a 
bark and opening the door. But the system 
is designed for one or the other—either 
the remote opens the door, or the bark 
recognizer does—not both. 




Can you have more than one 
alternate path in the same use case? 


A! Absolutely. You can have alternate 
paths that provide additional steps, and 
multiple ways to get from the starting 
condition to the ending condition. You can 
even have an alternate path that ends the 
use case early... but we don’t need anything 
that complicated for Todd and Gina’s dog 
door. 


A complete patn tnrougfn 


a use case, from tke first 
step to tlie last，is called 


a scenario . 


Exactly. Because an alternate path 
that has additional steps is just a set of steps 
that can occur as part of another step on the 
use case’s main path. When Fido gets stuck 
outside, the main path steps are 6 and 7 ， 
so the alternate path steps start at 6.1 and 
go through 6.5; they're an optional part of 
Step 6. 


Most use cases kave 
several diWerent scenarios, 
tut tkey always skare tke 
same user goaL 
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alternate paths are optional 



Cases Ex^osedi 


This week’s interview: 

Confessions of an Alternate Path 


HeadFirst ： Hello, Alternate Path. We’ve been hearing that you’re really 
unhappy these days. Tell us what’s going on. 

Alternate Path ： I just don’t feel very included sometimes. I mean, you can 
hardly put together a decent use case without me, but I still seem to get ignored 
all the time. 

HeadFirst ： Ignored? But you just said you’re part of almost every use case. It 
sounds like you’re quite important, really. 

Alternate Path ： Sure, it may sound that way. But even when I’m part of a use 
case, I can get skipped over for some other set of steps. It really sucks... it’s like 
I’m not even there! 

HeadFirst ： Can you give us an example? 

Alternate Path ： Just the other day, I was part of a use case for buying a CD at 
this great new online store, Musicology. I was so excited... but it turned out that I 
handled the situation when the customer’s credit card was rejected. 

HeadFirst ： Well, that sounds like a really important job! So what’s the 
problem? 

Alternate Path ： Well, yeah, I guess it’s important, but I always get passed over. 
It seems like everyone was ordering CDs, but their credit cards were all getting 
accepted. Even though I was part of the use case, I wasn’t part of the 
most common scenarios. 

HeadFirst: Oh, I see. So unless someone’s credit card was rejected, you were 
never involved. 

Alternate Path ： Exactly! And the finance and security guys loved me, they just 
went on and on about how much I’m worth to the company, but who wants to 
sit there unused all the time? 

HeadFirst ： I’m starting to get the picture. But you’re still helping the use case, 
right? Even if you’re not used all the time, you’re bound to get called on once in 
a while. 

Alternate Path: That’s true; we all do have the same goal. I just didn’t realize 
that I could be important to the use case and still hardly ever get noticed. 

HeadFirst ： Well, just think... the use case wouldn’t be complete without you. 

Alternate Path ： Yeah, that’s what 3.1 and 4.1 keep telling me. Of course, 
they’re part of the alternate path for when customers already have an account 
on the system, so they get used constantly. Easy for them to say! 

HeadFirst ： Hang in there, Alternate Path. We know you’re an important part 
of the use case! 
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requirements change 


harpen your pencil 

、 How many scenarios are in Todd and Gina’s use case? 

How many different ways can you work your way through Todd and Gina’s use case? 
Remember, sometimes you have to take one of multiple alternate paths, and sometimes 
you can skip an alternate path altogether. 


out 

-followed 

above 七 

vou stavbcd- 




Todd and Nina's Poa Pook version 2.3 

What the Poor l?oes 


Main Path 

1. Fido barks to be let out. 

2. The bark recognizer "hears" a bark. 

炙 The bark recognizer sends a request 
to the door to open. 

4. the dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1. The door shuts automatically. 

6.2. Fido barks to be let back inside. 

6.?. The bark recognizer "hears" a 
bark (again). 

6.4. The bark recognizer sends a 
request to the door to open. 

6.5. The dog door opens (again). 

Z Fido goes back inside. 
i- the door shuts automatically. 


Alternate Paths 

2.1. Todd or Wwa hears Fido barking. 

3.1. Todd or Wna presses the button 
ow the remote control. 




6.3.1. Todd or Wwa hears Fido 
barking (again). 

6.4.1. Todd or Wwa presses the 
button ow the remote control. 


I, Z l, i l, ^ ^>.1, ^>.Z, ^>3.1, ^ 1, ^ 5. 


2 . 


6 . 


3. 


4 . 


8 . 


>u rwight ir>o-t Y\Ctd 

all o-f these blanks. 
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one use case, multiple scenarios 


Sharpen your pencil 

、、 answers 


How many scenarios are in Todd and Gina’s use case? 


How many different ways can you work your way through Todd and Gina’s use case? 
Remember, sometimes you have to take one of multiple alternate paths, and sometimes 
you can skip an alternate path altogether. 


Todd ayid Nina's Poq Poor, version 2.3 

What the Poor Poes 


Main Path 

1. Fido barks to be let out 

2. The bark recognizer "hears" a bark. 

3. The bark recognizer sends a request 
to the door to open. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1. The door shuts automatically. 

6.2. Fido barks to be let back inside. 

6.3. The bark recognizer "hears" a 
bark (again). 

6.4. The bark recognizer sends a 
request to the door to open. 

6.5. The dog door opens (again). 

1 Fido goes back inside. 

S. The door shuts automatically. 


Alterwate Paths 


2.1. Todd or (r\m hears Fido barking. 

3.\. Todd or ^ma presses the button 
oh the remote control. 


6.5.1. Todd or 夺 iwa hears Fido 
barking (again). 

6.4.1. Todd or 备 iwa presses the 
button ov\ the remote control. 


This is just -the use 
s rwolih 

1 I , 2 J , 孓 I , 午, $ 石,石.1,么 Z , HI , △.弓 , 7, 召 


you -take ^>3.1, you'll 
also take S-tcp 么 . 午 ./. 

IX 

5 I, Z, Z, ^ ^ ^1, △. 午 J, 么弓 , 7 , 必 


take j2. m 午 , s 么 , g_ 6. i 2., ^ ^ ^ j>.l t ^ ^ ^ g 

i\\t 。? Wal 、 

3. ^ 工上 31! 午，弓， k 1 公 _ 7. <的<>七 else >_ 


pido yts 

studk ou-b'«dc- 


4 I , Z . I , 3.1, 午 , 弓»1,么 .2 •，么 .3, △.午 ，么 "7, 召 

|jf 7 ou -take stc ? 
always also take Stc? ^ 1 - 


8 . clsc> 
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Let's get ready to code.. 


requirements change 


Now that our use case is finished up, and we 5 ve figured out all 
the possible scenarios for using the dog door ， we’re ready to 
write code to handle Todd and Gina’s new requirements. Let’s 
figure out what we need to do... 


今 。 ahead “ — 

m av^v add'>t>o^al , 

d'»s6ovcvcd v/ovk'»^5 

七七 he s6cv\av-»os 

-fov i\\t ^ Ao^ door 
ov\ ⑽ 





I think we should recheck our 
requirements list against the new use 
case. If Todd and G\r\as requirements 
changed, then our requirements list 
might change too, right? 


0 


Any time you change your use 
case, you need to go back 
and check your requirements. 

Remember, the whole point of a good 
use case is to get good requirements. If 
your use case changes, that may mean 
that your requirements change, too. Let’s 
review the requirements and see if we 
need to add anything to them. 


Todd and Nina's Pog Poor: version 2.2 

Requirements List 

1. The dog door opening must be at least 1 T tall. 

2. A button on the remote control opens the dog door 
if the door is closed, and closes the dog door if the 
door is open. 

$. Once the dog door has opened, it should close 
automatically if the door isn't already closed. 
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evolving the requirements list 


Finishing up the requirements list 

So we need to handle the two new alternate paths by adding a couple 
extra requirements to our requirements list. We’ve gone ahead and 
crossed off the steps that our requirements already handle, and it looks 
like we need a few additions to our requirements list: 


TVicv-c arc 
v-cally *tv/o 

here: 

do^s kavk, ar\d 
do^ door. 


TVicsc arc 
steps *tV^air\ Z 

a^d W*t *tKc 

arc *tV^c sa^c 
ds -fov "tV^osc 
cavl'icv- S-tcps. 


Todd awd frma's Poq Poor ： version 2.3 

What the Poor Poes 



Mam Path 

卜 . Fido barko to bo let (Htf.- 

2. The bark recognizer "hears" a bark. 

The bark recognizer sends a request 
to the door to open. 

4 The ^ WnnK n p nMC 

$. Fido ym-jMil&id&i 
6. Fido docs hio btfetucss. 

Tho rfnnr ghiifs automatie^livu 
Q tn ho Ipt har.k uasidg. 

6.3. The bark recognizer "hears" a 
bark (again). 

6.4. The bark recognizer sends a 
request to the door to open. 


Alternate Paths 


2,1. Todd or 6ma hears Fido barkwg. 


V\fe -took tart 
(J( moS't 
•bV^csc wam 
S 七 c?s m 
七 ev 2-. 



(HA\ ^ ^ ftiMa hearslidfl 
barking (aptrt)r- 

M\. Todd oi Oiyia prmeytHe 
bull oh on fho rrwotP rowtr-ol 


j! Tido goco back in»tcte. 
^Ibc door ohuto nnfnwntifi 


pteps Oh 

I Wc 

* So al^ady 
I Shelled -the 

l^c^uivcmch-ts -to 

U>rt o-f -these. 


Hcv-C av-c *tv^c *tv/o 
v-c c \u>v*cw'Cy\*ts y/c need 
*to add *to ouv- list 


Todd and Nina's Pog Poor, version 2.3 

Requirements List 

1. The dog door opening must be at least 1 T tall. 

2. A button oh the remote control opens the dog door 
if the door is closed, and closes the dog door if the 
door is open. 

$. Once the dog door has opened, it should close 
automatically if the door isn't already closed. 

4. A bark recognizer must be able to tell when a dog 
is barking. 

5. The bark recognizer must open the dog door when 
it hears barking. 
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requirements change 


Now wc caw start coding the 
dog door again 

With new requirements comes new code. We need some 
barking, a bark recognizer to listen for barking, and then 
a dog door to open up: 





DogDoorSimulator.java 

/ 

F»do is 

ouls'idc tVic s'/stem, 
so v/c do^*t y^ccd ^ 
object W. lAfe 
C^Y\ \uis*t simulate 

\\vn\ D3V*k>ir\^ \Y\ 
Po^PooV*S»mula*toV". 


TW»S IS i\\t wc-tv^od ouv- 

s<iwc -tv^a-t v/c k , 
have tailed 叫 Wc P 崎 
V^ayrdv/avc V^cavs a bavk. 


t si l ikc 

th ^ c s hairdwa^c ahd 
so^W i, the dog doc ： -the 
doov * + ahd youv^ ad c . 



BarkRecognizer.java 


^ s-till hCC( j ^ wv .j^. c 

the udt 4^ the bark 

^ttoo^yz^r. Wt\\ do 

*that oh -tKc hex-t page. 



DogDoor.java 

ti 7 

丄 d u: 代:二 d ^ 

6att ,sotW,s6odedocs,t 

6V>a^c at a \、 

fj；. ^ u 9 h ^ ^ill 嘛 ki h3 0h 

J 〔 Uih 3 the io do 上七 

the ^ustomcir wahts, this is a 

9 I ^ i0h ^ d «i9- 

,s s °l'd. Wo 4/ 3 
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recognizing barks 


Was that a "woof" 1 heard? 

We need some software to run when Doug’s hardware “hears” 
a bark. Let’s create a BarkRecognizer class, and write a 
method that we can use to respond to barks: 



BarkRecognizer.java 


sW the dog door that this 
is aiiached -to ih 

public class BarkRecognizer { variable. 

private DogDoor door; ^ — Tiic B3V"kRc£.o^y\iz^\r r\ccds *to know 

f door »*b >will opcir\. 

public BarkRecognizer(DogDoor door) { 
this.door = door; 


public void recognize(String bark) { 

System. out. print In ('' BarkRecognizer : Heard a 
bark + '、'"）； 
door.open(); 

} v 

\ … 3hd up 

七 he do^ door. 


Allv/C -to do is ou-tpu-t a 

二心 he * 卜 


ba^ii^n ^ n heavs a 



e no . 

Questions 




That’s it? It sure seems like the BarkRecognizer 
doesn’t do very much. 




But what happens if a dog other than Fido is 
barking? Shouldn’t the BarkRecognizer make sure it’s 
Fido that is barking before opening the dog door? 


Right now, it doesn’t. Since the requirements are 
simple—when a dog barks, open the door—your code is 
pretty simple, too. Any time the hardware hears a bark, it 
calls recognize () in our new BarkRecognizer 
class, and we open the dog door. Remember, keep things as 
simple as you can; there’s no need to add complexity if you 
don’t need it. 


Very interesting question! The BarkRecognizer 
hears all barks, but we really don’t want it to open the door 
for just any dog, do we? We may have to come back and 
fix this later. Maybe you should think some more about this 
while we’re testing things out. 
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requirements change 


I think with this new class, weve got 
everything we need. Lefs test out the 
BarkRecognizer and see if we can make 
Todd and Gina happy again. 


First, let’s make sure we’ve taken care of Todd 
and Gina’s new requirements for their door: 


TK'»s is ay\o*tKcv- 
*fov* 

pou^. Fov- Y\O^I) 
y/C 乙 3 灼 USC 

Simula 七 ov *to yt 
a kav-k *to *t^c 

V-C£. 0 ^I 2 jCV-, 

七 es 七七 he SO^*fcw3^C 

y/e y/v-o*tc.- - - — 


Todd and (riKia's Poa Poor, version 2.3 

Requirements list 


1. The dog door opening must be at least 1 T tall. 

2. A button on the remote control opens the dog door 
if the door is closed, and closes the dog door if the 
door is open. 

$. Once the dog door has opened, it should close 
autowiatically if the door isn't already closed. 

4. A bark recognizer must be able to tell when a dog 
is barking. 

5. The bark recognizer must open the dog door when 
it hears barking. 




This is -the toAt 
v/c jus 七 y/irote … 
anytime the 
v-cdoj^izjcv heavs a 
bavk, i 七 opc^s the 

dog doo\r. 


t;1 

如 H k . ^ wa ” avc — 
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test drive 


Power up the new dog door 

Use cases, requirements, and code have all led up to this. Let’s 
see if everything works like it should. 

o Update the DogDoorSimulator source code: 

public class DogDoorSimulator { 



DogDoorSimulator.java 


public static void main(String[] args) { 

DogDoor door = new DogDoor(); 

BarkRecognizer recognizer = new BarkRecognizer(door); 


Remote remote = new Remote(door); 




W\t door, 

let W 


( - - // Simulate the hardware hearing a bark 

]/\lt don’t System. out. print In (''Fido starts barking .’’）； 


veal V\avd>wavc, 
so >wcll 
SIWVAlS't^ 
V^avd^avc 

a 

bavk . 氺 


recognizer . recognize (''Woof "); 



System. out. print In (''\nFido has gone outside •••〃）； 
System. out. print In (''\nFido A s all done . . . r, ); 


ouir hew 

B^V~k/^c^o^hi2^v- 
so^-twa<rc gc-ts -to 
9° a^tioh. 


try { 



Wic siwul3*bc 
some 

^>dss'm^ V^cvc- 


Thread.currentThread() .sleep (10000); 
} catch (InterruptedException e) { } 


System. out. print In (. . . but he's stuck outside ! 


// Simulate the hardware hearing a bark again 
System. out. print In (''Fido starts barking . ,r ); 
recognizer . recognize (''Woof "); 



Wc 七 es 七七 he 
ou"tsulC) 

just bo make su\TC 
CVCV-Y"tWm^ w>\rks 

like i 七 should- 


System. out. print In (''\nFido A s back inside. ••〃）； 

- |sfot»6c *b^a*b Todd a^d 

^'md a 

bu-tW rtr^ott 

七 W»s Wc avowd- 


au*tho\rs o-f -this book smdcvcly *to 

•mdude ha\rdv/a\rc 七 dould hcav- do^s ba\rk'm^... 
bu 七 mav-ketmj msis-ts 七 ha 七 nobody would buy a 
book pv-ided at 6{0 -fijuv-cl 
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requirements change 


❺ Recompile all your Java source code into classes. 



o Run the code and watch the humanless dog door go into action. 


A -fcv/ stCov\ds 
pass 
y/W»lc P»do 

^lays oiA*b»dic- 




File Edit Window Help YouBarkLikeAPoodle 


% java DogDoorSimulator 
Fido starts barking. 

BarkRecognizer : Heard a 'Woof f 
The dog door opens. 

Fido has gone outside... 

Fido^ s all done... 

••.but he's stuck outside! 

Fido starts barking. 

BarkRecognizer : Heard a 'Woof f 
The dog door opens. 

Fido's back inside.•• 



harpen your pencil 

Which scenario are we testing? 





Can you figure out which scenario from the use case we’re testing? 
Write down the steps this simulator follows (flip back to page 123 to 
see the use case again): 
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answers and open doors 


Sharpen your pencil - 

answers 


Which scenario 
are we testing? 


Did you figure out which scenario from the use 
case we’re testing? Here are the steps from the 
use case on page 123 that we followed: 

I, Z, Z, t>, ^1, ^>3, ^>A) ^ 1, ^ 




^ y° u ^9^ oui wh^ 

二!， P 严财如 

七 he dog d OOY ? 


v Clrsioh 


In our new version of the dog door ， 
the door doesn’t automatically close! 


In the scenarios where Todd and Gina press 
the button on the remote control, here’s the 
code that runs: 


Todd 

d^a ?v-css 

i\\t WtW o 灼 

tW»s todt 
also sc*ts u\> 
a kfi 

dlosc doov 


public void pressButton () { 〃 

System, out .println (''Pressing the remote control button. ••") 

if (door•isOpen()) { 

door.close (); 

} else { 

door•open (); 


final Timer timer = new Timer (); 
timer.schedule(new TimerTask() { 

public void run() { 

door.close(); 
timer.cancel(); 

}, } 5000); 


-this timcv 

弓 s ^ohds ; 5h d the sends a 
{o ihc dog doo^io 


class 
Remote 
press¬ 
Button ()1 
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requirements change 


But in BarkRecognizer, we open the 
door, and never close it: 



BarkRecognizer.java 


pou^, ovmcv ^ ou 5 s 
po^ poov-s, dtt\dc^ 七七 

V^e k^ov/s 
you should do. 



Even I can figure this one 
out. Just add a Timer to your 
BarkRecognizer like you did in the 
remote control, and get things 
working again. Todd and Gina are 
waiting, you know! 


What do YOU 

Doug’s 


think about 
idea? 
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duplicated code sucks 



I think Doug's lame. I don’t want to 
put the same code in the remote 
and in the bark recognizer. 


O 



Duplicate code is a bad idea. 
But where should the code 
that closes the door go? 


^ ^ m 愐 


use 
oy \ 产 


Well, closing the door is really 
something that the door should 
do, not the remote control or the 
BarkRecognizer. Why don’t we have the 
DogDoor close itself? 


0 


Let’s have the dog door close 
automatically all the time. 

Since Gina never wants the dog door left 
open, the dog door should always close 
automatically. So we can move the code 
to close the door automatically into the 
DogDoor class. Then, no matter what 
opens the door, it will always close itself. 
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requirements change 


Updating the dog door 

Let’s take the code that closed the door from the Remote 
class, and put it into our DogDoor code: 



DogDoor.java 


public class DogDoor { 
public void open() { 

System, out .print In (''The dog door opens .’’）； 
open = true; 


have io aaa 


价 eihd 






final Timer timer = new Timer (); 
timer.schedule(new TimerTask() { 

public void run() { 

close (); 

timer .cancel () , K/ .. , , 

y nlov/ the door closes 

}, 5000); 心巧 . ^ aAA 

devices that da 灼 

o^tv\ ihc door. l^liCc! 


,s is -the todt 
that used io be ih 


public void close () { 

System, out .print In (''The dog door closes."); 
open = false; 


Simplifying the remote control 

You’ll need to take this same code out of Remote now, since 
the dog door handles automatically closing itself: 
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test drive the door 


A final test drive 

You’ve made a lot of changes to Todd and Gina’s dog door 
since they first called you up. Let’s test things out and see if 
everything works. Make the changes to Remote . java and 
DogDoor. java so that the door closes itself, compile all your 
classes again, and run the simulator: 



Ycsl TV^c doov 


File Edit Window Help PestControl 


% java DogDoorSimulator 
Fido starts barking. 

BarkRecognizer : Heard a 'Woof f 
The dog door opens. 

Fido has gone outside... 

Fidels all done... 

The dog door closes. 

•••but he's stuck outside! 

Fido starts barking. 

BarkRecognizer : Heard a 'Woof f 
The dog door opens. 

Fido's back inside... 

The dog door closes. 


What would happen if Todd and Gina decided they wanted the door 
to stay open longer? Or to close more quickly? See if you can think of 
a way to change the DogDoor so that the amount of time that passes 
before the door automatically closes can be set by the customer. 
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requirements change 


Sometimes a ckangfe in requirements reveals 
protlems witk your system tkat you dictn’t 
even know were tkere. 


Ckangfe is constant，and your system skoulct 
always improve every time you work on it. 



arpen your pencil 


Write your own design principle! 

You’ve used an important design principle in this chapter related to 
duplicating code, and the dog door closing itself. Try and summarize the 
design principle that you think you’ve learned: 



You 二七 a ” *to / 

Wom 山 6k k 七 ^ a 
laW- S*t'«ll, -take youv best 5 uCSS - 


you are here ► 
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ooa&d toolbox 



More 

A Tools for your 00A 备 P Toolbox 

You’ve learned a lot in this chapter, and now it’s 
time to add what you’ve picked up to your OOA&D 
toolbox. Review what you’ve learned on this page, 
and then get ready to put it all to use in the OOA&D 
cross on the next page. 


good Cv>su\rc 70UV system 

Y/ovks Tike youv tusWcv-s e 平己七 . 

Make su^TC youv \rc<\u*»\rcmc^*b CoyJtr all 
stc^s m use dascs (or youv 〒七 ern. 

Use You\r use tascs *to -f md ou*t about 

youv- ^us-bomCV-s -fov-^ot "to tell you- 

Youv use tascs Will reveal .^om^lclc 
ov v-C^utV-CwC^'ts *t^ai y ou 州吵七 

have -bo add to youv sysiem. 

Youv- v-c^u^cm^-b Y/-.II aUays (ay>a 

y"OY/) OVCV* 

Q^Pv-mdiples 

^>6a)psula 七 e v/ha 七 vaviw. 


TWe was 

Ohc hew 
^ui\rcrhCh-t 
P'r'^iplc you 
leached, but its 
!^po\rbht 0hC / 


5SS5 ㈤ 

vest o*f codt m ouv aff. 


BULLET POINTS 




■ 


■ 


■ 


■ 


■ 


■ 


■ 


■ 


Requirements will always change 
as a project progresses. 

When requirements change, your 
system has to evolve to handle 
the new requirements. 

When your system needs to work 
in a new or different way, begin 
by updating your use case. 

A scenario is a single path 
through a use case, from start to 
finish. 

A single use case can have 
multiple scenarios, as long as 
each scenario has the same 
customer goal. 

Alternate paths can be steps 
that occur only some of the time, 
or provide completely different 
paths through parts of a use 
case. 

If a step is optional in how a 
system works, or a step provides 
an alternate path through a 
system, use numbered sub¬ 
steps, like 3.1,4.1, and 5.1, or 
2.1.1,2.2.1, and 2.3.1. 

You should almost always try 
to avoid duplicate code. It s 
a maintenance nightmare, and 
usually points to problems in how 
you’ve designed your system. 
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requirements change 



OOA&D Cross 

The puzzles keep coming. Make sure you’ve gotten all the key 
concepts in this chapter by working this crossword. All the 
answer words are somewhere in this chapter. 



Across 

2. Wc made this redportSrbIc far the 

dflg door. 

4. This whul you foKcnv jn u ma^l uf 

寸 he trmc. 

5. When your use olsb changes, these often 

change wall ， 

6. Requirements qI ways change over_ . 

<0, We had to add this "ho our dog door to 

TfiHH And’ 

IQ. When your system chong«s p you sh^urd 
updote this befere writing cod^. 

ll T C9M often have_ 

^ceruriod. 

I? Mnny rftnl-WffirlH npplifflitinFK iFivnlvK both 
io ftwuri: urd thii, 

I3L. TVie ofi 0 cortitcin 會 ijn Software anafyfi^ and 
de£rq-n. 



1. Xf o dtep is a p^Jondij thii in yeur u^c 

co^e. 

Z. rtlwoyss utaid _ uodK. 

3. A Set of Steps that dom ■會 QFwayf accur in 

your use case. 

7. Bo ih\i to things that vary T 

9. The irurn path rS aP^o cd〖ed this, 

10. Cvtry ^ccruno in a use, cade ^bar&£ 會 he 



you are here ► 
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4 analysis 

Taking Your Software 
into the Real World 



It’s time to graduate to real-world applications. 

Your application has to do more than work on your own personal 
development machine, finely tuned and perfectly set up; your apps 
have to work when real people use them. This chapter is all about 
making sure that your software works in a real-world context. You’ll 
learn how textual analysis can take that use case you’ve been 
working on and turn it into classes and methods that you know are what 
your customers want. And when you’re done, you too can say: “I did it! 
My software is ready for the real world!” 


this is a new chapter 
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it’s a dog-loving world 


Owe dog, two dog, three dog, four... 

Things are going well at Doug’s Dog Doors. The version of the dog door you 
just developed in Chapter 3 is selling like crazy... but as more doors get installed, 
complaints have started coming in: 


I loved your new model, with the bark 
recognizer. But now that youVe got it installed at 
my house, it opens up every time the neighbors' 
dogs bark. Thafs not what I wanted when I 
O bought this thing! 






r 

rtollVs doov 

Should ^ 


•••bu-fc ii J ： 


s 




U P all ih c 

do0s ih -the 

^cijbo^rhood bav-k, -too. 
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analysis 


Your software has a context 

So far, we’ve worked on writing software in a vacuum, and 
haven’t really thought much about the context that our 
software is running in. In other words, we’ve been thinking 
about our software like this: 


i\\t 

v/ovld, ev 伏产 
uses ouv 

like 

七 *to. 




The Perfect World ^ 


Analysis kelps 

neighborhoods he 代 . 


But our software has to work in the real world, not just 
in a perfect world. That means we have to think about our 
software in a different context: 





\oi wove d W 


The Real World 


I 於仏 e v-cal >wo\rld, -t^cv-c av-c 

doy, tats, vodc^is, 扣 d a host 

o-f o*tKc\r pvoblcms, dll sc*t b> 
StVOM up youv SO-f*tv/c 


J 3 V-C. 


you ensure 
your system 
works in a 
real-world 
context. 


The key to making sure things work and that the real world 
doesn’t screw up your application is analysis: figuring out 
potential problems, and then solving those problems — before 
you release your app out into the real world. 


you are here ► 
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whafs going wrong? 


Identify the problem 


The first step in good analysis is figuring out potential 
problems. We already know that there’s a problem when 
there are multiple dogs in the same neighborhood: 




flh 


Remote ^ 

『 Holly use Kc\r 

v-emote do^-tvol {o 
ofCh tKc door- y\o 

pvoble 你 s Kc\rc- 


open() 


O 


0 



J\^t kavk 

V^cav-s Bv-utc 巧 

door, >wWWis jus 七 
y/V^at rtollY 命 ts. 


But V>e\re’s iV>c 

problem". *tV>c bavk 
vedo^niz^v also V>c3vs 
othev- do^s, ar>d ofCK>s 
-the door (or *too. 



open () 



0 ^3 

ognizer _ 
updatel 



BarkRecognizer 
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analysis 


Plan a solution 


It looks like there’s a change we need to make in what our 
system does. Do you know what it is? Below is a part of the 
diagram detailing how the dog door system works: 


Bv-udc has takch Pido’s 

plade". bcttcv update 
youv dia^am a bit. 


TV^c remote >s ?avt 

m 、 

latest Holly hears Bruce 

do^ doov. barking 



(53^ Holly presses the 
button on the remote 
control 



® Bruce barks to be let out 


The bavk vedojhiz^v 
•s pav-t of the maih — 

path, ahd it ； s Ictimj *m 
all do^s ； hot just the 
ov/hcv-^s dog. 


⑧ The bark recognizer 
“hears” a bark 


⑧ The bark recognizer 
sends a request to the 
door to open 


④ The dog door opens 
® Bruce goes outside 


iarpen your pencil. 

、 What’s wrong with this diagram? 

It’s your job to figure out how you would fix the dog door. You 
can add steps, remove steps, or change steps." it’s up to 
you. Write down what you think you need to change, and then 
mark your changes on the diagram above. 


you are here ► 
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adding the missing step 


parpen your pencil 

answers 



What’s wrong with this diagram? 


( 53 ) Holly hears Bruc 
barking 




(Q) Holly presses the 
button on the remote 
control 



® Bruce barks to be let out 


⑧ The bark recognizer 
“hears” a bark 


丁 he ba\rk Kcav-s 

叫 dogs, is but 
it's the s-tcp tKats 
B problem. 


④ The dog door opens 
® Bruce goes outside 


卜 step ' 如 

vc6o^zjCV* y\ccds -to 

evaluate tV>c bark *»-t V>cavs 

see BvutC, OV 

some o 七 W Ao^ 


door to open 

® If it’s Bruce barking, 
send a request to the 
door to open 




s. 


ba\rk is Bv*u^c ； 
"the ba\rk \rcdojhiz^\r 
schd ah opCh \rc^ucst -fco 
doj doo\r. 
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e no . 

Questions 


I came up with a different solution. 
Does that mean my solution is wrong? 


A: No, as long as your solution kept all the 
dogs except for Bruce from going in and out of 
the dog door. That’s what makes talking about 
software so tricky: there’s usually more than one 
way to solve a problem, and there's not always 
just one “right” solution. 


In my solution, I turned step 3 of the 
original use case into two steps, instead of 
just replacing the existing step. Where did I go 
wrong? 


A! You didn’t go wrong. Just as there is 
usually more than one solution to a problem, there 
is usually more than one way to write that solution 
in a use case. If you use more than one step, 
but have the scenario with other dogs barking 
handled, then you’ve got a working use case. 




So these use cases really aren’t that 
precise, are they? 


Actually, use cases are very precise. If 
your use case doesn’t detail exactly what your 
system is supposed to do, then you could miss 
an important requirement or two and end up with 
unhappy customers. 

But, use cases don’t have to be very formal] in 
other words, your use case may not look like 
ours, and ours might not look like anyone else’s. 
The important thing is that your use case makes 
sense to you, and that you can explain it to your 
co-workers, boss, and customers. 


Write your use cases in 
a way tkat makes sense 
to you, your j>oss, ana 
your customers. 


Analysis and your use 


cases 


let 


you 


slio 


w 


customers, managers, 
and otlier developers 
kow your system works 
in a real world context* 


「槪^- 

There’s an important addition that needs to be made to the dog 
door system, in addition to what’s shown on page 150. What is it? 
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keep your use case up to date 


Update your use case 


Since we’ve changed our dog door diagram, we need to go 
back to the dog door use case, and update it with the new 
steps we’ve figured out. Then, over the next few pages, we’ll 
figure out what changes we need to make to our code. 


Amoved all tKc vc-fcvchdcs 

io oy/hC\rs a^d do^s, so 

how use cast will wovk -fov* 

ill Pougs 匕 usto 略 s . 


I 07 C) 

pido. Uc*t s 

use ,, 

ov/y\CV* s do^ 
^V*OW V\ 0 >w OY\ 


Wc\rc is the 
updated step 
■tKat deals 
with ohly 
^llowihj -the 
ovmeir’s dog 
… 3hd out 
doom. 


{jo 

substc?) *to°* 一 


The Ultimate Poq Pool： version ^.0 

What the Poor Poes 

Main Path 

Alternate Paths 

1. The owner's dog barks to be let out. 

/T - ~1 

2. The bark recognizer "hears" a bark. 

2.1. The owner hears her dog 
barking. 

3 . If ifs the owner's dog barking, the 

3.1. The owner presses the button 

bark recognizer se^ds a request to 
the door to opew. 

4. The dog door opens. 

5. The owner's dog goes outside. 

6. The owner's dog does his business. 

6.1. The door shuts automatically. 

6.2. The owner's dog barks to be let 
back inside. 


6.3. The bark recognizer "hears" a 

6.3.1. The owner hears her dog 

bark (agaih). 

barking (again). 

6.4. If ifs the owner's dog barkiwg. 

6.4.1. The owner presses the 

the bark recognizer se^ds a 
request to the door to opeh. 

6.5. The dog door opens (again). 

1 The owner's dog goes back inside. 

S. The door shuts automatically. 



Instead o-P 
[odd dy>d 
ra ' ma , ov * Holly , 
let’s \ us 七 use 


ov/ir>c\r. 


w 
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analysis 


Don*t we need to store the 
owners dog's bark in our dog door? 
Otherwise, we wotVt have anything 
to compare to the bark that our 
bark recognizer gives us. 


We need a new use case to 
store the owner’s dog’s bark. 

Our analysis has made us realize we need 
to make some changes to our use case —— 
and those changes mean that we need to 
make some additions to our system, too. 

If we’re comparing a bark from our bark 
recognizer to the owner’s dog’s bark, then 
we actually need to store the owner’s 
dog’s bark somewhere. And that means 
we need another use case. 





arpen your pencil 


Add a new use case to store a bark. 


You need a use case to store the owner’s dog’s bark; let’s store the 
sound of the dog in the dog door itself (Doug’s hardware guys tell 
us that’s no problem for their door technology). Use the use case 
template below to write a new use case for this task. 


You should ^ccd 
or\ly steps 
-fov 七 Wis use 
case, 3r^d 
avc^-t a^Y 
alleviate pa-tV^s 
-to viovv-Y about. 



。灼 “ "this is 

ouv second use 
匕 ase, le 仏 label 

^ H des^ibes 
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a new use case 


Sharpen your pencil - 

answers 


Add a new use case to store a bark. 


You need a use case to store the owner’s dog’s bark; let’s store the 
sound of the dog in the dog door itself (Doug’s hardware guys tell us 
that’s no problem for their door technology). Use the use case template 
below to write a new use case for this task. 


We need *to i\\t 
t%ati details oi 七 Wis, 
t-t's a Kavd^avc issue- 


丁 his is wha-t wc heed io 
do... add a method -to 
DojDoov -to s-tov-c -the 
ovmev's dog’s bdrk. 


The Ultimate Poq Poor version $.0 
Storing a dog bark 

T. The owner's dog barks "into" 

the dog door 


2 . The doa door stores the 

owner's dog's bark. 


theve are no 

Dumb Questions 


Do we really need a whole new 
use case for storing the owner’s dog’s 
bark? 


Is this really the result of good 
analysis, or just something we should 
have thought about in the last two 
chapters? 


Yes. Each use case should detail 
one particular user goal. The user goal 
for our original use case was to get a dog 
outside and back in without using the 
bathroom in the house, and the user goal of 
this new use case is to store a dog’s bark. 
Since those aren’t the same user goal, you 
need two different use cases. 


A! Probably a bit of both. Sure, we 
probably should have figured out that we 
needed to store the owner’s dog’s bark 
much earlier, but that’s what analysis is 
really about: making sure that you didn’t 
forget anything that will help your software 
work in a real world context. 


How are we representing the 
dog’s bark? 


That’s a good question, and it’s one 
you’re going to have to answer next... 
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analysis 



Design Puzzle 


You know what classes you already have, and you’ve got two use cases 
that tell you what your code has to be able to do. Now it’s up to you to 
figure out how your code needs to change: 


Your task: 


o Add any new objects you think you might need for the new dog door. 

❺ Add a new method to the DogDoor class that will store a dog’s bark, and 
another new method to allow other classes to access the bark. 

o If you need to make changes to any other classes or methods, write in those 
changes in the class diagram below. 

Add notes to the class diagram to remind you what any tricky attributes or 
operations are used for, and how they should work. 


\A/ C used tlass d 哼 a 厂 s 

badk m ⑽仏丨 ; ” 
sV^on, V>as \6 todc-lcvcl 




av-c -tlic atbributes )( 
you\r dlass, ^ 1 

usually up L 

with 七 he dlass ； s 
membev- variables... 

tV^csc avc 

dlasss 0 \>cvat» 0 ir\s, 

avc usuall7 ^ 
tlasss —V«6 ^ettods. 




Doujs 

Kav-dwairc se^ds 
"the souhd o-f "the 
^uv-irch-fe dog’s bavk 
"to "this wtliod. 



Casc wc defiled Oh 

/5 午 . 


BarkRecognizer 


door: DogDoor 



recognize(String) 
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fixing the dog door 

A talc of two coders 

There are lots of ways you could solve the design puzzle on page 155. 
In fact, Randy and Sam, two developers who Doug’s Dog Doors just 
hired, both have some pretty good ideas. But there’s more at stake 
here than just programmer pride — Doug’s offered the programmer 
with the best design a sparkling new Apple MacBook Pro! 

Randy: simple is best, right? 

Randy doesn’t waste any time with unnecessary code. He 
starts thinking about how he can compare barks: 


H o-f 

ktcl ?ov/cv. 




Bark sounds are just 
Strings, so I'll store a String for 
the owners dogs bark in DogDoor, and 
add a couple of simple methods. 
Piece of cake! 


尺 ady adds a h 
^HowcdB^k variable io 
^ ,|as. 


public class DogDoor { 

private boolean open; 

private String allowedBark; 

public DogDoor() { 

open = false; 


public void setAllowedBark(String bark) 
this.allowedBark = bark; 


public String getAllowedBark() { 

return allowedBark : 


TWis settmj 

七 he bav-k, WiA 祕 

ouv- Y\t^N use tasc 

-fotused OY\- 


/ / etc 


Oi\)cr classes cav\ yt 
ihe owKiC^r^s do^s bav-k 
"tKis wBiod. 


HevVs Ra^dy s dass 
d'ld^drw -fov* Po^Poov. 


DogDoor 

open: boolean 

allowedBark: String 

open() 

close() 

isOpen(): boolean 

setAllowedBark(String) 
getAllowedBarkj): String 
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analysis 


Sam: object lover extraordinaire 

Sam may not be as fast as Randy, but he loves his 
objects, so he figures that a new class devoted to 
dog barks is just the ticket: 



tlass. 


- ^ Bark 

sound: String ^ - 

getSound(): String ^ - 

equals(Object bark): boolean 


心州 pla^s -fco s-fcov-c 
"the sound o( a dogs 
Ba^rk as S ih 

h |S hCw Bairk tlass... 

...3 method *to \rc*tuv^ 

七 he sou^d o-f 七 he Bark... 


...a^d ^ c<\uals() w»c*tW 
•to alloy/ otV>cv objects 


Writing code based on a class diagram 
is a piece of cake. 

You’ve already seen that class diagrams give you a lot of information 
about the attributes and operations of a class. Your job is to write 
the code for Sam’s Bark class based on his class diagram. We’ve 
written just a bit of the code to help get you started. 


cfQ^irpen your pencil 




Saw 


public class _ { 

private _ _ 


public _( 

this. — 


public _ _() { 


if (__ instanceof __) { 

Bark otherBark = (_)_ 

if (this ._• equalsIgnoreCase ( 

return ; 


return 
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writing the Bark and DogDoor classes 



arpen your pencil 

answers 


Writing code based on a class diagram 
is a piece of cake. 


Your job was to write the code for Sam’s Bark class based on his 
class diagram. Here’s what we did: 


Bairk class 

/ 


Jus-t like (Ud7 
did, Saw \as\^ 
a -to 

s-tov-c "tV^c public 

bavk sound- this 


public class gark 
private String 


sound 


… bu*fe he’s 
capped -the 

sound up in a 
Bav-k objedt 


public 


Park 

(String 

sound 

= sound ； 

String 

getSoudd o 


sound 


Bark 


sound: String 


getSound(): String 
equals(Object bark): boolean 


return 


sound 


S ㈣ 

— dass ，氣如 , 


public 


boolean 


equals 


(Object bark 


if ( bark instanceof — 
Bark otherBark =( Park 

sound 


Park 


bark 


if (this. 
return 


•equalsIgnoreCase ( othergark . sound )) 


true 


return 


false 


丁 Vis mrtliod 
mdkes suve i*t Ii3s 
olhO*tiiC\r Bavk 

{ object to 匕 orwpavc 

itsd-f agams 七 … 

〜 a …扣 d "thch 

^ompa^s £hc two 
sounds. 


Sam: updating the PogPoor class 

Since Sam created a new Bark object, he takes a 
slightly different path than Randy did in updating 
his version of the DogDoor class: 
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open: boolean 

allowedBark: Bark 

openQ 
close() 

isOpen(): boolean 

setAllowedBark< 


vcvs'ioy\ ok 
po^Poov s-bves a 
^avk object 
Vust a • 


Sam s jc-t sei 
°fC\rd-iior)S deal 
^ B 扣 k objedts, 

^oi 


(Randy’s) DogDoor 

open: boolean 
allowedBark: String 

open() 

close() 

isOpen(): boolean 

setAllowedBark(§tnngJ) 

getAllowedBark():CString7 











































analysis 


Comparing barks 

All that’s left to do is add a comparison of barks into BarkRecognizer’s 
recognize () method. 


Randy: 111 just compare two strings TKc 

s cv\i {o 

When the BarkRecognizer class gets a signal from the . ls 

hardware that a dog is barking, it also gets the bark, and wi+h 仏 

compares it to what’s stored in the door: 


public class BarkRecognizer { 

public void recognize (String bark) { 

System. out. print In ('' BarkRecognizer : 
''Heard a 、’’ + bark + 

if (door.getAllowedBark().equals(bark)) 
door.open(); 

} else { 

System, out .println (''This dog is 〃 + 
''not allowed."); 

} 


i\\t bavk 




skortd m ^ dooV 


ZJtX 


{ 令 




/ / etc 


Sam s todt lets Wk 
stoWm po^poov v^dlc 

,om ? a^sor,s. H-.S 

aclcjatcs Wk to^\so^ to 

-Sc Bavk object 


Sam: Til delegate bark comparison 

Sam is using a Bark object, and he lets that object havd a 

take care of all the sound comparisons: j u y s m ^ ^ ^ 

a ha^rk object how ; 
•^ot jus-f ： -the £-tvihj 
kvk sound, like Rav\dy. 


public class BarkRecognizer 


public void recognize (Bark bark) { 

System. out. println ('' BarkRecognizer : 〃 

''Heard a ' + bark. getSound () + ； 

if (door.getAllowedBark().equals(bark)) { 

door.open(); 

} else { 

System, out .println (''This dog is not allowed. 〃〉 

} 


// etc 
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Delegation Detour 

delegation m Sam’s dog door: 
aw in-depth look 

Sam is doing something very similar in his Bark and 
DogDoor classes. Let’s see exactly what’s going on: 


❶ The BarkRecognizer gets a Bark to evaluate. 

Doug’s hardware hears a dog barking, wraps the sound of 
the dog’s bark in a new Bark object, and delivers that Bark 
instance to the recognize () method. 



Q 


M 


pou^s ^a^rd^a^rc a 

(jio^ bav'km^, dvc3*tcs 
a now Bav-k object 



Thc ba^rk is passed 


❺ BarkRecognizer gets the owner’s dog’s bark from DogDoor 

The recognize () method calls getAllowedBark () on the dog door it’s 
attached to, and retrieves a Bark object representing the owner’s dog’s bark. 



recognize() 


^ getAllowedBark() 


BarkRecognizer 



/ \ 

Bark 

Rowlf! J 




DogDoor 

J 、 

TV\c doj door y-ctuv^s tV\c 

BaA object 

{\\t dojs bavk- 
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BarkRecognizer delegates bark comparison to Bark 

The recognize () method asks the owner’s dog’s Bark object to see 
if it is equal to the Bark instance supplied by Doug’s hardware, using 

Bark.equals(). 


Delegation Detour 


^11 dome back io 

r/ S io win -the 

制 ook Pb 0hdc 

3 。七 a hhdlc 0h dclcjatioh. 


Hey there, allowedBark. Can you see if this 
other Bark that I have matches you? I really 
don’t know much about what makes Barks the 
same, but I'll bet that you do. 



bavk -("VOWV pou^ s V>3V*d>w3V*C- 


ks 


Bark decides if it’s equal to the bark from Doug’s hardware 

The Bark object representing the owner’s dog’s bark figures out if it is equal to 
the Bark object from Doug’s hardware... however that needs to happen. 



It really takes one Bark to understand another 
Bark, you know? So let's see if we're really equal. 


You got that right. Let's compare properties. 


TV,c dc-taAs W. tWs 

‘ ⑽ a 代 

加 0 W …咖 

door a— 


Its U ? ^ Bavk ^ ^d\t 
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Delegation Detour 

The power of loosely 
coupled applications 

In Chapter 1, we said that delegation helps our 
applications stay loosely coupled. That means that 
your objects are independent of each other; in 
other words, changes to one object don’t require 
you to make a bunch of changes to other objects. 

By delegating comparison of barks to the 
Bark object, we abstract the details about 
what makes two barks the same away from the 
BarkRecognizer class. Look again at the code 
that calls equals () on Bark: 


public void recognize(Bark bark) { 

System. out. print In ('' BarkRecognizer : 〃 

''Heard a 、’’ + bark. get Sound () + 

if (door.getAllowedBark().equals(bark)) { - 

door.open(); 

} else { 

System. out. print In (''This dog is not allowed .’’）； 


Now suppose that we started storing the sound 
of a dog barking as a WAV file in Bark. We’d 



TV^c details Vuw 
e<\udUO >wov*ks avc 
sWielded av/ay i\\t 

method- 


equals () 


Bark 


Bark 



need to change the equals () method in the 


Bark class to do a more advanced comparison 
of sounds and account for the WAV files. But, 


since the recognize () method delegates bark 
comparison, no code in BarkRecognizer 
would have to change. 


So with delegation and a loosely coupled 
application, you can change the implementation 
of one object, like Bark, and you won’t have to 
change all the other objects in your application. 
Your objects are shielded from implementation 
changes in other objects. 


Delegation skields 
your objects from 
implementation cnang[es 
to otker obj ects in your 
software. 
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analysis 


Pack to Sam, Randy, and the contest … 

With Randy’s quick solution, and Sam’s more object-oriented one, let’s see 
how their applications are working out: 


O 


0 






docs 

Simple tor 外狄 ， scm 


© 




if (door.getAl 1 owedBar 

.equals(bark )){ 
door.open(); 


Sam’s dodc uses objedis 
delegation {p gei ilic job do 


Randy ANP Sam: It works! 

Both Randy and Sam ended up with a working 
dog door that let in only the owner’s dog. 


We both got it right? So 
◎ who won the laptop? 
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dog doors and the real world 


Maria wow the MacPook Pro! 



To both Randy and Sam’s surprise, Doug announces 
that Maria, a junior programmer he got to work for the 
company as a summer intern, has won the laptop. 


TW»s is Mav'»a. Tvy *to 


Randy: Oh, this is ridiculous. My solution worked! That 
laptop is mine, not some intern’s! 

Sam: Whatever, man. My solution worked, too, and I used 
objects. Didn’t you read Head First Java? An object-oriented 
solution is the way to go... the laptop’s mine! 

Maria: Umm, guys, I don’t mean to interrupt, but I’m not 
sure either one of your dog doors really worked. 


Sam: What do you mean? We tested it. Bruce barked, 
“Rowlf!” and the door opened up... but it stayed shut for the 


other dogs. Sounds like a working solution to me. 


Maria: But did you do any analysis on your solution? Does 
your door truly work in the real world? 


Randy: What are you talking about? Are you some sort of 
philosophy major? Is this like a “there is no spoon” sort of 
thing? 

Maria: No, not at all. I’m just wondering... what if Bruce 
were to make a different sound? Like “Woof’’ or “Ruff ”？ 


Sam: A different sound? Like if he’s hungry... 
Randy: ...or excited... 


Maria: ...or maybe... he really needs to get outside to use the 
bathroom. That’s, ummm, sort of how things work in the real 
world, isn’t it? 

Randy and Sam: I guess we hadn’t thought about that... 



O 



Q 



O 


o 


Bv-udc "»s a scv\s'»t»vc 

从 c sublctics 

⑽必 aW W 七 
Wis 七 a^oss. 
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analysis 


So what did Maria do differently? 


Maria started out a lot like Sam did. She created a Bark object to 
represent the bark of a dog. 


Bark 

sound: String 

getSound(): String 
equals(Bark): boolean 


I knew objects and 
delegation were 
important! 


Alairia khcw she’d 
dclcga-tioirj via -fehc c^ualsO 

method, just as S 如 did. 


But Maria went even further: she decided that since a 
dog might have different barks, the dog door should 
store multiple Bark objects. That way, no matter how 
the owner’s dog barks, it still gets outside: 


DogDoor 

open: boolean 

allowedBarks: Bark [*] 

open() 
close() 

isOpen(): boolean 

addAllowedBark(Bark) 
getAllowedBarks(): Bark [*] 


W 饮” ^ally 

wch-t down a di-Pfc^ch-t 

广 .She decided i\yai 

thc do 9 doo^r should sic 

^ GhC 
„ ihe owhe^s do 9 dah 





Wb^dicv-^^ about 七 
asW«sb? C^k tW»s out- 



VMLVp Chse 




We’ve added something new to our class diagrams: 


allowedBarks: Bark R] 


Anytime you see b\r 把 ke*ts, i 七 

mdidates 七 he of an 

a*ti\ribu*tc ： how many o( a dev-ta'm 
七 y 产 the attribute car\ hold. 


TV>c tV)c allo>wcdBavks 

attribute »s 



Ahd this asievisk r^edhs that 

allowcdBajrks hold a, ⑽ I4 d 
number o-f Bavk objedts. 


you are here ► 


165 
















the use case tells you what to do 


How in the world did you know 
to store multiple barks? I never 
would have thought about a dog 
having multiple barks. 


Q 



It’s right here 
in the use case. 


O 


⑽七 tilled 

lost but 

^-^uv-cs Mana 一吵七 

be Wis tidkc-t -to 


^usih 9 o h ou ^. 
Wih use case hcv-c, hot 

the hew one wc developed 

c^licv- |his dhapt 饮 . 


The Ultimate Poa Poor, version 变 0 

Opewi 叫 /closing the door 


IVs tKc doa 払 at 
七 V\c -fodus Kcv*c> ⑽七 
just a s^c6'i-f '»6 bav-k. 


Mam Path 

1. The owner's dog barks to be let out. 

2. The bark recognizer "hears" a bark. 
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$. If ifs the owwer>arkiwg, the 
bark recognizer sends a request to 
the door to open. 

4. The dog door opens. 

5. The owner's dog goes outside. 

6. The owner's dog docs his business. 

6.1. The door shuts automatically. 

6.2. The owner's dog barks to be let 
back inside. 

6.3. The bark recognizer "hears" a 
bark (again). 

6.4. If it's the owner's dog barking. 


Alternate Paths 

2.1. The owner hears her dog 
barking. 

i\. The owner presses the button 
oh the remote control. 


6.3.1. The owwer hears her dog 
barking (again). 

6.4.1. The owner presses the 
button ow the remote control 































analysis 


Pay attcwtiow to the mum iw your use case 

Maria’s figured out something really important: the nouns 
in a use case are usually the classes you need to write and 
focus on in your system. 


Your job is to circle each noun (that’s a person, place, or thing) in the 
use case below. Then, in the blanks at the bottom of the page, list all the 
nouns that you found (just write each one a single time; don’t duplicate any 
nouns). Be sure to do this exercise before turning the page! 


cfQ^rpen your pencil 


w dof a (or 

\JO\A ^ould tWt\t 

w ovmCV* s doj J' 


The Ultimate Poa Poor, version 3.0 

OpeHihg/closing the door 


Mam Path 

1. The owner's dog barks to be let out. 

2. The bark recognizer "hears" a bark. 


3. If ifs the owwef<^>Hciwg, the 
bark recognizer sends a request to 
the door to open. 

4. The dog door opens. 

5. The owner's dog goes outside. 

6. The owner's dog does his business. 

6.1. The door shuts automatically. 

6.2. The owner's dog barks to be let 
back inside. 

6.3. The bark recognizer "hears" a 
bark (again). 

6.4. If ifs the owwer / <8og5)arkiiig # 
the bark recognizer sends a 
request to the door to open. 

6.5. The dog door opens (again). 

7 The owner's dog goes back inside, 
g. The door shuts automatically. 


Alternate Paths 

2.1. The owner hears her dog 
barking. 

3,\. The owwer presses the button 
ow the remote control. 


6.3.1. The owner hears her dog 
barking (again). 

6.4.1. The owwcr presses the 
button ovi the remote control. 


■(: he houhs 
■that you dialed 
use tasc ih 
仏仪 bbhks. 

〆 
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noun analysis 


t^harpen your pencil 

answers 


Your job was to circle each noun (that’s a person, 
place, or thing) in the use case below. Here’s the 
use case with all the nouns circled. 


The Ultimate Poq Poor: version 3.0 

OpehiHg/closing the door 


Main Path 

1. The owwer'<|og))arks to be let out. 

2. Th((bark rccogwize^'hcars" ^bar^> 

3. Ifit^s the owj^rldo^arkmg, the 
dS3c recogwizer^ewds a<^egucsj3 r o 

thC^gor^o operT 

4. Thc(iloq door^pews. 

5. The owwer's<3^fl]80cs(Suts|de2) 

6. The owwer'^3S2^ioes his business. 

6.1. The^oo^shuts automatically. 

6.2. The owwer'scjogybarks to be let 
baclQwsid^ 

6.3. Th^h ark rccogwize^ 'hcars" a 
CE^^Iagaiw). 

6.4. If ifs the owwer's^g^arkmq, 
th^hark rccoqwizeDsewds a 
(^cques^yfo the^iiodDto open 

6.5. Thfl(dog doo^bpens (again) 

7 The owwer'^3ocflaocs back inside. 

S. Th^door>huts automatically. 


Alternate Paths 

2.1. ThcCgwwcfjpears herc^o£) 
barking. 

Th^owwer^rcsscs t 
ow thc^cwote cowtro 


thijutto^ 

5t^> 


6.J.I. Thgcowwerioears hercSSS^ 
barking (again). 

6.4.1. TheCowMeFuresses the 
<ggttoto>w thcc tcmote coyff rolr > 


the (owner's) dog bark recognizer dog door 

the owwer_ request_ remote control 

the button inside/outside bark 


- We're aire all ihc houhs we 

^Icd ih |hc use 幻 sc. 
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analysis 





OK, I get it... 
almost all of these nouns 
are the classes in my 
system. 


Maria: That’s right. That’s how I figured out I needed a 
Bark class... it showed up in the use case as a noun in Steps 2 
and 6.3. So I created a Bark class. 

Randy: So that’s where I went wrong... if I had looked at the 
use case and circled the nouns, I would have known to create 
a Bark class, too. 

Maria: Probably. A lot of times, even if I think I know what 
classes I need, I double-check my ideas with the nouns in my 
use case to make sure I didn’t forget anything. 

Sam: But you don’t need a class for some of those nouns, like 
'the owner” or “request,” or even “inside.” 

Maria: That’s true... you still have to have some common 
sense, and understand the system that 
you’re building. Remember, you need 
classes only for the parts of the system you 
have to represent. We don’t need a class for 
'outside 55 or “inside” or “the owner’’ because 
our software doesn’t have to represent those 
things. 


Looking at tlie 

nouns (and verts) 


Randy: And you don’t need a class for 
“the button” because it’s part of the remote 
control —— and we already do have a class for 
that. 

Sam: This is all great, but I was just 
thinking... I came up with a Bark class, too, 
and I didn’t need the use case to figure that 
out. 

Maria: Yeah... but then you didn’t end up 
with a dog door that really worked, did you? 

Sam: Well, no... but that’s just because you 
stored more than one Bark object in the 
dog door. What does that have to do with 
the use case? 


m your use 
case to figure 
out classes and 
metliocts is callect 


textual analysigt 
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the nouns are the objects 


It’s all about the use case 


Take a close look at Step 3 in the use case, and see 
exactly which classes are being used: 


、祕 、 dof k a 七 

v,c (WU«d a 山 ss W 
i\\\s s'mtc tV>c doj a 如 o 

outs.de tV>c 




3 . If ifs the owner's dog barking, the 
bark recognizer sends a request to 
the door to open. 



3；,_ 

• 仏 0 心如 ^ actually 
唧吻 h^d by 心 b 扣 k 7 

^od o, d d J 


BarkRecognizer 


door: DogDoor 


recognize(Bark) 


DogDoor 

open: boolean 
allowedBarks: Bark [*] 


open() ^ - 

close 。 

isOpen(): boolean 
addAllowedBark(Bark) 
getAllowedBarks(): Bark [*] 


There is wo Park class here! 

The classes in use here in Step 3 are BarkRecognizer and 
DogDoor... not Bark! 
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analysis 


3 . If the owner's dog's bark 
matches the bark heard by the 
bark recognizee the dog door 
should open. 



tteve S £tc\> ( V"Om *tV\C use 

cast (or 

Wis do^ doov- |ir\ Wis S 七 c? 
w bavV’ k a y \ o \ ay \- 


Step 3 in Randy’s use case looks a lot like Step 3 in our 
use case... but in his step, the focus is on the noun M bark ’’， 
and not “the owner’s dog.” So is Randy right? Does this 
whole textual analysis thing fall apart if you use a few 
different words in your use case? 


What do vou think? 



.T T; L . ook dlosc| y ^ gi, ? b. d ocs 
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words matter in use cases 


Owe of these things is wot like the other... 

It looks like Randy’s Step 3 is actually just a little bit different than our original 
Step 3 … so where did Randy go wrong? 


on^mal use 63SC ba6K 

m CV^aftcv ^ — 


3 . If it's the owner's 


dog barking, the bark 
recognizer sends a request 
to the door to open. 


瓜 d s l usc 

^as C -tha-t Raridy up wi-th 

-the same doj doov. 

/ 

$. If the owner's dog's bark 
matches the bark heard 
by the bark recognizee 
the dog door should open. 


Focus: owner's dog 

Our original Step 3 focuses on the owner’s dog... 
no matter how the dog sounds when it barks. So if the 
owner’s dog barks with a loud “Rowlf!” one 
day, but a quiet “ruff” the next, the system will 
let the dog in, either way. That’s because we’re 
focusing on the dog, not a particular bark. 


Focus: owner's dog's bark 

Randy’s use case focuses on the owner’s 
dog’s bark... but what if the dog has more 
than one sound it makes? And what if two 
dogs bark in a really similar way? This step 
looks similar to the original Step 3, but it’s 
really not the same at all! 




O 


o 


祕 ^ ♦ 加 

\ Acer 

^ all 

份 “c’s barks. 




州士 h 3 poorly 
Writteh l } 

° h, y o-P Bv-udc ； : 

will jc-t 

oui o-f -the 
dog doo\r. 
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analysis 


there are no 

Dumb Questions 


So you’re telling me as long as I 
write use cases, all my software will work 
like it should? 

A! Well, use cases are certainly a good 
start towards writing good software. But 
there’s a lot more to it than that. Remember, 
analysis helps you figure out the classes 
from your use case, and in the next chapter, 
we’ll spend some time talking about good 
design principles in writing those classes. 

I’ve never used use cases before, 
and I’ve never had any problems. Are you 
saying that I have to write use cases to 
create good software? 

A! No, not at all. There are plenty of 
programmers who are good at their jobs, 
and don’t even know what a use case is. 

But if you want your software to satisfy the 
customer more often, and you want your 
code to work correctly with less rework, 
then use cases can really help you nail 
your requirements down... before you make 
embarrassing mistakes in front of your boss 
or a customer. 


It seems like this stuff about 
nouns and analysis is pretty tricky, and 
I’m not any good at English grammar. 
What can I do? 


But what if I make a mistake like 
Randy did, and use a noun in my use case 
when I shouldn’t? 


You really don’t need to focus too 
much on grammar. Just write your use 
cases in conversational English (or whatever 
language you speak and write in). Then 
figure out what the “things” are in your use 
case—those are generally the nouns. For 
each noun, think about if you need a class to 
represent it, and you’ve got a good start on a 
real-world analysis of your system. 


Randy’s mistake—using “bark” as a 
noun in step 3 of his use case—had nothing 
to do with Randy’s grammar. He didn’t think 
through the use case, and how his system 
would work in the real world. Instead of 
focusing on getting the owner’s dog outside, 
he was worrying about one specific bark. He 
focused on the wrong thing! 

When you write your use case, reread it, and 
make sure that it makes sense to you. You 
might even want to let a couple of friends or 
co-workers read through it, too, and make 
sure it will work in the real world, not just in a 
controlled environment. 


A good use case clearly and 
accurately explains wnat 
a system does, in language 
tliat’s easily understood. 


Witli a good use case complete, 
textual analysis is a quick ana 


easy way to figure out tne 
classes in your system. 
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the power of analysis 


OK, I see what Randy’s mistake was ： 
he got hung up on a bark, not the owners 
dog. But even in the correct use case, we 
don’t have a Dog object. So what*s the 
point of all this, if our analysis doesn't tell 
us what classes to create and use? 


0 



Textual analysis tells you what 
to focus on，not just what 
classes you should create. 

Even though we don’t have a Dog class, textual 
analysis gave us an important clue about what our 
system really needs to do: get the owner’s dog in 
and out of the door, regardless of how he barks. In 
other words, our analysis helped us understand 
what to focus on... and it’s not a specific bark. 

Once you’ve figured that out, it makes sense to 
think about what a dog really does. Does a dog 
always bark the same way? That’s when Maria 
figured out her real-world solution: she realized 
that if the owner’s dog could bark in more than 
one way, and the point was getting the owner’s dog 
outside, then the dog door needed to store all the 
ways that the dog could bark, not just one of them. 
But Maria would have never figured this out if she 
hadn’t really analyzed her use case. 


f^rpen your pencil Why is there no Dog c|ass? 

When you picked the nouns out of the use case, one that kept showing up was “the 
owner’s dog.” But Maria decided not to create a Dog object. Why not? Below, write 
down three reasons you think Maria didn’t create a Dog class in her system. 


2. 

3. 
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analysis 


Remember: pay attcwtiow to those wouws! 

Even if the nouns in your use case don’t get turned into classes in your 
system, they’re always important to making your system work like it should. 


tw.s wse tase, ''oner's d<>i 

a Wtit’s 

3 . If ifs the owwer ; s dog barking, 
the bark recognizer sends a 
request to the door to open. 


心 hi ， ，一 



The point is that the nouns are what you should 
focus on. If you focus on the dog in this step, 
you’ll figure out that you need to make sure the 
dog gets in and out of the dog door~whether he 
has one bark，or multiple barks. 



TWlS toWtt{ ： \OY\ 

bavks csscir\t»all7 

tW»s »s 

? arb use 63SC 


DogDoor 


open: boolean 
allowedBarks: Bark [*] 


open() 

close() 

isOpen(): boolean 
addAllowedBark^ 
getAllowedBar[ 





BarkRecognizer 


door: DogDoor 
recognize(Bark) 


EvCh 仏 。吵仏 is r^cihod gc 
s ， h 9 * c kirk, i*ts puv-posc is -to 

^ wf)idh i£9 bav-ked. li v-ur 
though all the allowed basics 

do 9 door io see i-P this bavk 
*r^onr» -the owhev-s dog. 


Pay attention to 
tke nomis in your 


use case, even 
wken tkey aren’t 
classes in your 
system. 


Tkink aLout kow 
tke classes you ^ 
kave can support 
tke Lekavior your 
use case ctescritest 
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the verbs are operations 


It seems like if the nouns in the 
use case are usually the classes in 
my system, then the verbs in my use 
case are my methods. Doesn*t that 
make sense? 


The verbs in your use case 
are (usually) the methods of 
the objects in your system. 

You’ve already seen how the nouns in 
your use case usually are a good starting 
point for figuring out what classes you 
might need in your system. If you look at 
the verbs in your use case, you can usually 
figure out what methods you’ll need for 
the objects that those classes represent: 


0 



TV^c PojPoov- 
tlass -to 

V\3vc a 的灼 0 

and tloscO 

u 代 ov •七七 
vcv-b adtov^s. 


S' 


c 


The Ultimate Poa goon version 多 .0 

Opening/closing the door 


Mam Path 

1. The owner's dog barks to be let out. 

2 . The bark recognizer "hears" a bark. 

3 . If it's the owner's dog barking, the 
bark recognizer sends a request to 
the door to open. 

4. The dog duoft^pe?^ 

5. The owner's dog goes outside. 

6. The owner's dog does his business. 
)oCshuts^utomatically. 

6.2. The owner's dog barks to be let 
back inside. 

6.5. The bark recognizer "hears" a 
bark (again). 

6.4. If ifs the owner's dog barking, 
the bark recognizer sends a 
request to the door to open. 

6.5. The dog door opens (again). 

7 The owner’s dog goes back inside. 

S. The door shuts automatically. 


Alternate Paths 

2.1. The owner hears her dog 
barking. 



The owweNBTesses the buttoj 
ow the rcwotccowtroi. 


6.5.1. The owner hears her dog 
barking (again). 

6.4.1. The owner presses the 
button on the remote control. 


HcvVs ar\o*thcv vc\rb 
w |>vcsscs 

*tKc button." 0u\r 
Remote dlass has 
d pvcssBu*t*tor\0 
me 七 hod that 
rwatdlics up pc\rfcd*tly. 
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analysis 



Code Magnets 

It’s time to do some more textual analysis. Below is the use case for the dog door 
you’ve been developing. At the bottom of the page are magnets for most of the 
classes and methods we’ve got in our system so far. Your job is to match the class 
magnets up with the nouns in the use case, and the method magnets up with the 
verbs in the use case. See how closely the methods line up with the verbs. 


TKcv-c av-c 

lots o-f 
dlasses 
me 七 V>ods a 七 
七 V>is poiyv 七， 
so take 
youv* 七 iw'C. 



The Ultimate Pog Pook version 3.0 

Openmg/closmg the door 


Mam Path 

1. The owner's dog barks to be let out. 

2 . The bark recognizer "hears" a bark. 

$. If ifs the owner's dog barking, the 
bark recognizer se^ids a request to 
the door to open. 

4. The dog door ope^is. 

5. The owner's dog goes outside. 

6. The owner's dog does his business. 

6.1. The door shuts automatically. 

6.2. The owner's dog barks to be let 
back inside. 

6 .$. The bark recognizer "hears" a 
bark (again). 

6.4. If it's the owner's dog barking, 
the bark recognizer sends a 
request to the door to open. 

6.5. The dog door opens (again). 

7 The owner's dog goes back inside. 

S. The door shuts automatically. 


Remotf 


Alternate Paths 

2.1 The owner hears her dog 
barking. 

炙 1. The owner presses the button 
ow the remote control. 


6.^.1. The owner hears her dog 
barking (again). 

6.4.1. The owner presses the 
button ow the remote control. 


iote 


B^rtRe^mizer 
getSound() 

.izer 


DogDoor 


Do( 


recognize! 


recognize 


pres 


sButton() 


Bairk 


Remote 


DogDoor 


clos( 


recognize() 


ton () 


cL 


open () 


recog^^^ 


ssButton() 


sButton() 


getSound() 


"rkRecognizeijopenO^^ 




getAllowedBarks() 


getAllowedBarks() 
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textual analysis 



Code Magnets Solutions 


It’s time to do some more textual analysis. Below is the use case for the dog door 
you’ve been developing. At the bottom of the page are magnets for most of the 
classes and methods we’ve got in our system so far. Your job is to match the class 
magnets up with the nouns in the use case, and the method magnets up with the 
verbs in the use case. See how closely the methods line up with the verbs. 


The Ultimate Pog Pook version $.0 

Ope^mg/closiHg the door 



Mam Path 

1. The owner's dog barks to be let out. 
2 


BarkRecogni 


Koiitc 七 V>a 七 
mo s*t 七\^仪 

steps v/i 七 V\ou 七 a” 
majnets avc tWnr^S 
七 ha 七 ott\A^r ouisidc 
o*f system and 

i\\ai system 
v-catts -to. 





4. T 

5. The owner's dog^s outside. 

6. The omier^docidocs his business 

6 . 1 . m DogDoor 

6.2. T 



let 



back inside 


6 




BarkRecogni 


rkRecI 


getAllowedBarks() 

BarkRecogni zer 

requ 


ids a 


6.5. 


DogDoor 

DogDoor 


ppen() 

oJnO 


Z The oWier's dog go 

S.Th gj DogDoor 






l 

close () 




Alternate Paths 

\ 2 .\. The owner hears her dog 
barking. 

3.1 The 


out 


here! 


icr 

| pressButton() 



Remote 









6.5.1. The owner hears her dog 
barking (again). 

6.4.1. The own 
button ow 


pressButton() 



Remote 



The use tast still makes a lot sc^sc i\\t 

m plate! That's a good sign tKat ouv classes 
a^a avc domj c^adly t^cyVc su 代 osed 

+o so 七七七 system v/ill be a suttess. 
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analysis 


Sharpen your pencil 

answers 


Why didn’t Maria create a Dog class? 

When you picked the nouns out of the use case, one that kept showing up was “the 
owner’s dog.” But Maria decided not to create a Dog object. Why not? Here are three 
reasons we think Maria made the right choice. 




C 

TKcvc av-c v/Kcm 

You ‘jWt do Wt 

usually or\Yj y/Kcm Y ou 
wed ^ m 七⑽七 ^ 

do 灼’七 *to 

•mtcvat 七 Wrtv> tV\c do 汐 


1 The dog is external to the system, and you usually do^t need_ 

to represent things external to the system. 

2. Poq is^t a software object (and shouldn't be)... you usually don't represent living things 

with a class unless the system is going to store long-term information about that thing. 

^ Even if you had a Pog class, it wouldn't help the rest of the system. For example, you 

ca^t really "store" a Pog in the dog door; that doesn't make any sense. 

/oull ofictn see classes 
like Wscir ov- /Wahajcv", 
but "these ircpircscr>-fe 
ir> a sys-tem, oy 
tYtd\i ^av-ds 
Oir add\r«s«. A dofli 
⑽一 docs^i U ahy / 

those pa-t-tc^^s. 




You 6 ould V^avc a VC^ : 

r V ^ Vo0 \° W ^^ 

,eal l^e. Make su,e ^ a ?? UaWs a 
Ytovld 



e no . 

Questions 




So the nouns in the use case turn into classes, and the 


verbs turn into methods? 


It looks like the nouns that are outside the system don’t 
get turned into classes. Is that always true? 


A! That’s almost it. Actually, the nouns are candidates for 
classes... not every noun will be a class. For instance, “the owner” is a 
noun in the use case (check out Steps 2.1 and 3.1, for example), but 
we don’t need a class for that noun. So even though “the owner” is a 
candidate for a class, it doesn’t become a class in the actual system. 

In the same way, the verbs are candidates for operations. For example, 
one verb phrase is “does his business,” but we just couldn’t bear to 
write a pee (> or poop () method. We hope you’ll agree that we 
made the right choice! Still, textual analysis is a really good start to 
figuring out the classes and methods you'll need in your system. 


A! Most of the time it is. The only common exception is when 
you have to interact with something outside the system—like when 
there’s some state or behavior that the system needs to work with on a 
recurring basis. 

In the dog door system, for example, we didn’t need a class for the 
owner because the Remote class took care of all the owner-related 
activity. If we ever needed to track owner state, though—like if the 
owner was asleep or awake—then we might have to create an Owner 
class. 


you are here ► 
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maria’s class diagram 


From good analysis to good classes... 







… *bo do^ir\ V\cv-c? 




allowedBarks 


Rcwcwbcv, 

astcv-'sk n\t^ 
ytAllov/cdBavksO 
tBY\ y-ctuv-ir\ wulfc'plc 
Bav-k objects- 
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Bark 

sound: String 

getSound(): String 
equals(Bark): boolean 





















analysis 


^^-UML Investigation - 

Maria’s gone pretty crazy with her UML diagrams... do you think you can figure 
out what all she’s done? On the diagram below, add notes to all the new things 
she’s added, and try and figure out what the lines, numbers, and additional 
words all mean. We’ve written a few notes of our own to get you started. 


TV Remote dlass V^as 
a *to 七 he 

Po^Poov dlass. 



^lled 

爲 wedBavks, 一 


DogDoor 

open: boolean 

open() 

close() 

isOpen(): boolean 
addAllowedBark(Bark) 
getAllowedBarksQ: Bark [*] 


♦ allowedBarks 

* 


Bark 

sound: String 

getSound(): String 
equals(Bark): boolean 


► Aiders on page 184. 
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associations and multiplicity 


Class diagrams dissected 

There’s a lot more to a class diagram than boxes 
and text. Let’s see how some lines and arrows can 
add a lot more information to your class diagrams. 


勤的 7©uVc 

associations 

-to v-c\>v-csc^t 

a*bbr»Wtcs ， y ou 
usually do 

矜 。七 

3 *b*b"»bu"bc 七 七 

七 V>c asso 6 'iat»o»\ 

class's attv-'butc 

v/Wy Remote y\o 
lo^yv- V^as 3 door 
attvibutc ^cvc- 


^ solid I'mc ^ o^t tlass 

is tailed ar. gsso6iaW 

|t that or^lass is 

assodiated ^ 孙 。七 巧 

“evVta 灼此也 • ~ 、 


TVis line ^ocs -p\ro»»> 七 |^ 
sou\rdC dass (Rer^oic) 
io ii)c iay^ci dass 
^DojDoov). This medhs 
that tKc souvdc dlass, 
Remote, lias a*tt\riburte 
o( -type DojDoov-, tKc 

tav-grt dlass. 




TV^c po^Poov tlass V^as 

a 灼 attv-'bu-bc 

alioY/cdBavb, 
sWcs Bav-k objects. 



allowedBarks 


Bark 


* 


sound: String 



getSound(): String 
equals(Bark): boolean 
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analysis 


TV^c ttc attv “ c 

m \}\t souv-tc tlass is 
V^crc, at tV^c 
七 ⑼ d d ^ W . So 
如 Remote tlass V^as 
atV«bu*tc tailed door, oAr 
七 Po^Poov-. 


气 this assot\ai\oy,. Tf J s I ^ 

WUyp c ： 1 " ahy 

^ aUHbul 31 Cd " 

I 的 ‘ 咖严 s :r c — 

s i e ， the (W 3Uiribuic 

S W a 5i ， 3 l c Do3Zw 



door 1 


DogDoor 


open: boolean 


Com\>avc tV^is diayam "to 
Mav'ia^ oy\ I 召 。 • 6v ⑶ 

•t^ou 吵佔 e classes are m 
di 以 W ⑺七 plates, \{!s -tV^c SAME 

class diayam. So {\\t ▽ositu^ 
o-f i\\t classes oy\ tVic diajv-arrv 

doesn't w\a 七七 cv*. 

，0 ^rpen your pencil 


open() 

close() 

isOpen(): boolean 
addAllowedBark(Bark) 
getAIlowedBarksQ: Bark [*] 


A^wcirs -to ihis 


3\rc oh 


pajcjG^. 


cxcMise 


Based on the class diagram above, what types could you use for the 
allowed Barks attribute in the DogDoor class? Write your ideas below: 
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more uml 



TJML Investigation Complete 

Maria’s gone pretty crazy with her UML diagrams... see if you can 
figure out everything that she’s done. 


|-t looks like Remote do 伙七 

V^avc attr •“ 七 cs — “七 

oyve tiass 

{jo a^cv tlass, bat 
v^v^se 山孙 attv«butc. So 
tV,c Remote tlass st»ll docs 
V^avc ov>c attr’“tc- 

入 


The I'mc Joes -fv-om iV\c 
dass >wrtV> *to 

ihc class i\\ai is i\\t -type 

be •喊 


「he Remote dlass V^as 
d VC-fcV"Cir\6C *to 七 he 
pojpoov- dlass, usi% an 
a 七七 vibu 七 e ^amcd doov. 

TV^c Aoor 

V^olds a 4 弋 

poo^Poov ob〆. 



open: boolean 

open() 

close() 

isOpen(): boolean 
addAllowedBark(Bark) 
getAllowedBarksQ: Bark [*] 


―扣 ^ibui c 

广 d doo^ ^ 

仏尹 holds 3 si 
D °^ _ 




Po^Poov V\3s 3v\ 

a*t*tvibu*tc 匕 ailed 

allowcdBs^^- TV\c 

o^f 七 V\c atbribu 七 c is Bav-k 


•allowedBarks 


TWis as*tcvisk mc3y\s w 3y\ 
^ uy\limrtcd ^umbcv- W 


乂：二二 


WW a 於 





m 


a \\ 0 viC 



184 Chapter 4 






















analysis 



E 站 RciS6 

、 • 

^PLvtlPHS 



arpen your pencil 


answers 


Based on the class diagram below, what types could you use for the barks 
member variable in your DogDoor class? Write your ideas in the blank below: 

List Array, Vector ： etc. 


You ^ould ar\Y 
七 SU^OV-*ts rwult^lc 

values... most o-f *tV>c Java 
CoWttho^ classes >/ould v/od 




拉地 aW as 诎 js d 吟如 


posi-tiohed 
desses and 
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why use class diagrams? 


Randy: I may have missed creating a Bark class, but my 
solution wasn’t that bad, and I didn’t waste a bunch of my 
time drawing squares and arrows. 


Maria: Haven’t you ever heard that a picture is worth a 
thousand words? Once I had my class diagram, I had a pretty 
good idea about how my whole system was going to work. 

Randy: Well, yeah, I guess I can see that... but I had a good 
idea of how my system would work, too. It was just in my head, 
not drawn out on paper. 

Sam: I think I’m starting to come around on this UML thing, 
Randy. I mean, once you’ve got the use case, it’s pretty natural 
to do some analysis, and turn the nouns into classes. It seems 
like you wouldn’t have to spend as much time worrying about 
what should be a class, and what shouldn’t. 




sa»d OOAfP 70 U 

ycat so-fWvc, 

evevY Wc? T^ ,s ,s 
。说 叫 OOAfP 

mistakes m 70UV toAt- 


Maria: Exactly! I hate writing a bunch of classes and then finding out I did something 
wrong. With use cases and class diagrams, if I make a mistake, I can just scribble things 
out and redraw my diagram. 

Randy: Well, I guess that’s true. Rewriting code takes a lot more time than rewriting a 
use case or redrawing a class diagram... 

Maria: And you know, if you ever have to work with anyone else, you’re going to have to 
explain that system in your head to them somehow, right? 

Sam: I think she’s right, Randy. I’ve seen your whiteboard when you’re trying to explain 
your ideas... it’s a mess! 


Randy: OK, even I can’t argue with that. But I still think class diagrams don’t tell the 
whole story. Like, how is our code actually going to compare barks and figure out if the 
dog door should open up? 


Bark 


sound: String 

getSoundQ' String 
Rauals(Bark )： boolean 


DogDoor 


open: boolean 
allowedBarks: Bark 

open() 
close() 

isOpenQ: booleant^ 
addAllowedBark(Barl 
getAllowedBarksQ: Bark [*] 
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analysis 


Class diagrams aren't everything 

Glass diagrams are a great way to get an overview of your system, and 
show the parts of your system to co-workers and other programmers. 
But there’s still plenty of things that they don’t show. 


Class diagrams provide limited 
type information 


Bark 

sound: String 

getSound(): String 
equals(Bark): boolean 


allowedBarks 


»s a Ust. A 

VctW? else. 



丁 he same plroblem 
cxis-ts -Pom ircfeu^h 
types … y/Ka-fe type docs 

jctAllowcdBav-ksO v-rtu^h? 


Class diagrams don’t tell you how 
to code your methods 


BarkRecognizer 


door: DogDoor 


recognize(Bark) 


T L h，s says hothiha 

" bout ^ ai ，心 0 “| d 

l° '\ 0>r ^ it i3kes a 


Class diagrams only give you a 
10,000 foot view of your system 



lu ” 一， 匕;: d 

如 Remote 6lass,Wt ；is 
tw, .lass rcaWy ^ 


use tasc 
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whafs missing from the diagram? 



命 


命 


命 

Glass diagrams are great for modeling the classes you need to create, but they don’t provide all 
the answers you’ll need in programming your system. You’ve already seen that the dog door 
class diagram doesn’t tell us much about matching up return types; what other things do you 
think are unclear from this diagram that you might need to know to program the dog door? 

Add notes to the diagram below about what you might need to figure out in order to program 
the door. We’ve added a note about comparing barks to get you started. 



allowedBarks 


Bark 

sound: String 

getSound(): String 
equals(Bark): boolean 


o ON l 杳 J § el^vsuy ▲ 
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analysis 


So how does recoghizeO work wow? 

Maria’s figured out that her BarkRecognizer class should be able to compare 
any bark it receives against multiple allowed barks, but her class diagram doesn’t 
tell us much about how to actually write the recognize () method. 

Instead, we have to look at Maria’s code. Here’s the recognize () method of 
her BarkRecognizer, and how she solved the barking problem: 


("tcv-a-fcoir is a Java 
objcd-t tKa-t lets us 
walk iK\roujK 

ih a list - 


Jus 七 1’ike •，的 Sarw s 

todt, Mav'ia 
delegates Bav-k 
dom^av-isons -to 七 he 
Bav-k object. 




public void recognize(Bark bark) { 

System. out. print In ('' BarkRecognizer : Heard a 

bark. get Sound () + 、' r 〃）； 

List allowedBarks = door.getAllowedBarks() 

|^ | 

allowedBarks.iterator(); i.hasNext(); ) { 

=(Bark) i . next (), 


心心 s jettihg s 
whole list o-f Bav-k 
objects 4orh -the 
doj doov . 


for (Iterator 

Bark allowedBark 
if (allowedBark.equals(bark)) { 

door.open(); 
return; 


"This su\rc wc dor /七 keep 
loopi% o)r\tt wc ； vc -fouhd d maidK. 


^avk object. 


System. out. print In (''This dog is not allowed . ,r ) 


Maria’s textual analysis helped her figure out that 
her BarkRecognizer needed to focus on the dog 
involved, rather than the barking of that dog. 


TVis method V-cpvcsch-ts 
avx Ch-tilrc dog ： all -the 
bairkihj sounds -thai 
the dog tsiY\ make. 




is (ot\AStd a smjlc 
bark … on or^t soujid tKc doj makes, 
rattev -bV^a^ doj itself 
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puzzle solutions 



命 



命 

Add notes to the diagram about what you might need to figure out to 
program the door. 


命 


Excise 

、 *1 • 



Wha*b docs 

▽vessButto 灼 (） 

method 


Docs cadh system 
hve just a sihjle 
DojDoov objed-t? 


lA/V^ai -type is used 
*to s-fcov-C multiple 
Bark objects? 




op 伙。 3hd dloscO 
> si 如，仏 e doo^s 
s i^ie, oy- do they do 
sorhcihihj else, -too? 


I 七 ’s utrv£>lcdv* 3^Y 0 ^ 

tons-tvut-tovs -fov 七 hese classes 
mi^vt do •• oV* v/ha 七 av*jumC>r>"ts 
七 VC<\U1VC. 


来 These 3\rc jus 七為 -fev/ o-f *the y/c though 七 c4 ■- \4u\r 

a^sy/evs may be *to 七 3lly di-f-(*CVCh*ti i-f you *though*t o-f 
o*thc\r -things *tha*t *thc dldss diagram doesn't really show. 


190 Chapter 4 




















analysis 


arx^\ovAS 











So when do we get to 
see the final version of 
Marias dog door? 


BULLET POINT 


■ Analysis helps you ensure that your software works 
in the real world context, and not just in a perfect 
environment. 

■ Use cases are meant to be understood by you, your 
managers, your customers, and other programmers. 

■ You should write your use cases in whatever format 
makes them most usable to you and the other people 
who are looking at them. 

■ A good use case precisely lays out what a system 
does, but does not indicate how the system 
accomplishes that task. 


■ 


Each use case should focus on only one customer 
goal. If you have multiple goals, you will need to write 
multiple use cases. 


■ 


■ 


■ 


■ 


■ 


■ 


Class diagrams give you an easy way to show your 
system and its code constructs at a 10,000-foot view. 

The attributes in a class diagram usually map to the 
member variables of your classes. 

The operations in a class diagram usually represent 
the methods of your classes. 

Class diagrams leave lots of detail out, such as class 
constructors, some type information, and the purpose 
of operations on your classes. 

Textual analysis helps you translate a use case into 
code-level classes, attributes, and operations. 

The nouns of a use case are candidates for classes in 
your system, and the verbs are candidates for methods 
on your system’s classes. 
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brush off your coding chops 


Design Puzzle 


ril bet you expected to find 
all the code I wrote here, didn’t you? I 
wish... when I was transferring files to 
my new MacBook Pro, almost all of the 
code for my dog door got corrupted. 
Can you help? 


Maria’s old computer screwed up all the code she wrote for her dog 
door except for DogDoorSimulator. java, shown on the next page. 
All we’ve got to go on are the code fragments from her solution in this 
chapter, her class diagrams, and what you’ve learned about good analysis, 
requirements and OO programming. It’s your turn to be a hero... 

The problem: 

You need to code the dog door application so that it satisfies 
all of Doug’s new customers (that’s a lot of potential 
sales), especially the ones with more than one dog in the 
neighborhood. The door should operate just as the use cases in 
this chapter describe the system. 

Your task: 


o Start out by re-creating the dog door application as it was described in Chapter 
3. You can download this code from the Head First Labs web site if you want a 
jump start. 

Copy or download DogDoorSimulator. java, shown on the next page. 
This is the only file that survived Maria’s laptop meltdown. 

Make your code match up with Maria’s class diagram, shown on page 180. 

o Start coding! First concentrate on getting all of your classes to compile, so you 
can begin testing. 

o Use the DogDoorSimulator class to see if things are working like they 
should. 

o Keep up the analysis and coding until your test class’s output matches the 
output shown on the next page. Don’t give up! 

o Once you think you’ve got a working dog door, check your code against ours at 
the Head First Labs web site. We’ll be waiting. 
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public class DogDoorSimulator { 

public static void main(String[] args) { 

DogDoor door = new DogDoor(); 
door . addAllowedBark (new Bark (''rowlf 〃））； 
door . addAllowedBark (new Bark (''rooowlf ); 
door . addAllowedBark (new Bark(' 、 rawlf 〃））； 
door . addAllowedBark (new Bark (''woof ^)); 

BarkRecognizer recognizer = new BarkRecognizer(door); 
Remote remote = new Remote(door); 

// Simulate the hardware hearing a bark 
System, out. print In (''Bruce starts barking .”）； 
recognizer . recognize (new Bark (' 、 rowlf 〃））； 

System, out. print In (''\nBruce has gone outside ••.〃）； 



N 

T ^ ,s is ihc icsi 

^ ss ^ 

°J d Use U is 

^ you»r owh doo 
do °^ 


try { 

Thread.currentThread() .sleep (10000); 

} catch (InterruptedException e) { } 

System, out .print In ( v '\nBruce A s all done . . . r, ); 
System, out .print In . .but he's stuck outside !〃）； 


// Simulate the hardware hearing a bark (not Bruce!) 
Bark smallDogBark = new Bark (''yip ,,r ); 

System. out. print In (''A small dog starts barking."); 
recognizer.recognize(smallDogBark); 


try { 

Thread.currentThread() .sleep (5000); 
} catch (InterruptedException e) { } 


// Simulate the hardware hearing a bark again 
System. out. print In (''Bruce starts barking . ,r ); 
recognizer . recognize (new Bark (''rooowlf 〃））； 

System, out .print In (''\nBruce A s back inside . . . r, ); 



Hcrcs output 70U 

从 at 如 (Wr ^ov-ks 

Jfov B 一 , 
doy. 



I File Edit Window Help HollyLovesBruce ■ 


% java DogDoorSimulator 
Bruce starts barking. 

BarkRecognizer : Heard a 'rowlf f 
The dog door opens. 

Bruce has gone outside... 

The dog door closes. 

Bruce r s all done... 

•••but he's stuck outside! 

Bitsie starts barking. 

BarkRecognizer : Heard a 'yip' 

This dog is not allowed. 

Bruce starts barking. 

BarkRecognizer : Heard a 'rooowlf’ 
The dog door opens. 

Bruce's back inside.•• 

The dog door closes. 
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define me, please 





命 


命 


UML and use cases have a lot of terms that are similar to, but not quite the same 
as, the programming terms you’re already familiar with. Below are several OOA&D- 
related terms, and their definitions … but everything is all mixed up. Connect the 
term to the definition, and unscramble the mess. 


Hlilt5PL?dt9 



Class OiagRan 

OPeRatiPH 

AsspciatipH 

• • • 


Lists all the code-leVel constructs, along with 
theiv attributes and operations. 

This is the UML term that usually represents a 
method in one of your classes. 

Helps you figure out the candidates for methods 
on the objects in four system. 

Visually shows that erne class tas a relation to 
another class, often through an attribute. 

Equivalent to a member Variable in a class. 

Describes how many of a specific type can be 
stored in an attribute of a class. 


V 鄉 Anai^S 


You do this tQ youv use case tQ figure out wtat 
classes you need in youv system. 
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analysis 


^2 °°A&D Cross 

Yhn knnw vnn 1 h\tr if. tv^r a.n 


You know you love it … try another puzzling crossword 
to get those new concepts lodged firmly in your brain. 



Across 

1 . Use dhmjld u^e this kind of language. 

Ei. Every iJuaid i/rugram. hmi ojie of IhcSK fur 1 
each member variab 『 e. 

10. Thfs focuses an putting your application 
irrtD the correct context. 

12. Software aEwcyis work^ better in the 
+pitting Fnh th^n hp.rK 

13. AAaria won the laptop because paid 

atitfTtion 十 1 or the 

1 ^. Thrs reiertes one cPclss To on&ther 
lb. You write your ufie case yao c£lti 

_your customers 

17. Use cafieiS should ai welJ easify 

understood. 

2S. UML k this +ypa of modeling language. 


bown 

2 . ^rM lySr^ mohed dure yeur Qpp Neat ion worlf5 
『n Ihh jj 

3. An operc^on is UML-esfi far This.. 

4. Ycrn do this to your use cases to figure out 
the clashes and eperati&n^ in your systejn. 

6, He replaced Fido os this chapter's star. 

7 ClnS 窄 di-figimmS nrp. a grR/ii w/fty to gp.t 十 hk of 
yeur 

&. How many of q iype an ai ■ 十 ributa can hold is 

ris _ 

y. These types ot di-agmms are worth a 
thousand words to a programmer. 

13. Use aren't formal, but they are 


15. Verb ifi to opercit^on thNe k to atlv^hnj 十 e_ 


you are here ► 
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answers, answers, answers 



Ex^RciSe 










命 


命 


UML and use cases have a lot of terms that are similar to, but not quite the same 
as, the programming terms you’re already familiar with. Below are several OOA&D- 
related terms, and their definitions... but everything is all mixed up. Connect the 
term to the definition, and unscramble the mess. 


HPvH Ah3L 嫩 


AttriBvte 


Class 施細 " 


0p6Rat!OH 
: ASSPci3ibiPH 

• . - »i ■ ■ • 

VeRB Ah% 祕 



Lists all the code-leVel constructs, along with 
their attributes and operations. 

This is the UML term that usually represents a 
method in one your classes. 

Helps you figure out the candidates for methods 
on the objects in /our system. 

Visually sipws tlat one class las a relation to 
anotier class, usually through an attribute. 

Equivalent tQ a member Variable in a class. 


Describes how many a specific t/pe can 
stored in an attribute of a class. 


)e 


You do this tQ /our use case tQ figure out wtat 
classes you need in your system. 
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5 (part 1) good design 




eXible 


SQ^ware 



Nothing Ever Stays 
^. the Same 


Molly, I hope we never have 
to grow up. Lefs just stay like 
this forever! 


Change is inevitable. No matter how much you like your 


software right now, it’s probably going to change tomorrow. And the 


harder you make it for your software to change, the more difficult 


it’s going to be to respond to your customer’s changing needs. In 
this chapter, we’re going to revisit an old friend, try and improve an 
existing software project, and see how small changes can turn into 
big problems. In fact, we’re going to uncover a problem so big that 
it will take a TWO-PART chapter to solve it! 


this is a new chapter 
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9 oin 9b eyon d9Uita rs 

Rick's expanding 

Fresh off the heels of selling three guitars to the rock group Augustana, 
Rick’s guitar business is doing better than ever — and the search tool you 
built Rick back in Chapter 1 is the cornerstone of his business. 


O 


Your software is the best—I'm selling 
guitars left and right. Ive been getting 
a lot of business from Nashville, though, 
and want to start carrying mandolins, too. 

I figure I can make a killing! 




avc a 

sV^ouldir\ "b 
be -too 


Let’s put our design to the test 

We’ve talked a lot about good analysis and design being the key to 
software that you can reuse and extend... and now it looks like we’re 
going to have to prove that to Rick. Let’s figure out how easy it is to 
restructure his application so that it supports mandolins. 
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good design = flexible software 


Add support for mandolins to Rick’s search tool. 

Below is the completed class diagram for Rick’s guitar search app, just like it was 
when we finished up with Chapter 1. It’s up to you to add to this diagram so that Rick 
can start selling mandolins, and your search tool can help him find mandolins that 
match his clients’ preferences, just like he already can with guitars. 



arpen your pencil 


• ft 二以 

WMU 6lass 



W’ve moved r^os-t 
the pvopcvtics 
ou-t o-f -the dldss 
box and used 
^ssodia-tiohs ihsicad- 


•06 Ae/A 39 V 4 e^u 3 i|V 4 i 

5|^i| e ( os j-| ^mow4W409 mi 

… .i 叩处 ㈧ p^e e o(j : 丄 ; s(|fi 


^ohet -tha-t wc 
Qh w\ri-tc -these 
piropcv-tics oh 
cithev side o( -the 
3ssodia-tioh... -thcv-c s 

Jus-t use wha-t wovks 
bes£ -fov you. 


you are here ► 
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updating rick’s class diagram 


t^harpen your pencil 

partial 

answers 


Add support for mandolins to Rick’s search tool. 

Below is the completed class diagram for Rick’s guitar search app, just like it 
was when we finished up with Chapter 1. Here’s what we did first to add support 
for mandolins (well make some more changes over the next few pages). 


⑽ ㈣ 一 

so 

w Seated a 



getSerialNumberO: String 
getPriceO: double 
jsctPrice(float) 


Look s like wc ; v c 
3°^ yet n\o\rc hew 
陳 ^oiai^ 

3。… 3 Oh hc^c... 
wc；,1 look si ihese 
P^3C ZOh. 



Mandolin 



1 


Uc-t's dv-ca-tc a ^ 
tlass, Ma^dol'm, 

-to VC^V-CSC^t 
wa^dol'ms. u just 
a set, v^cll ty'tdkt 
a A/la^dolmS\>ct 
£,}3ss -Pov* wd 灼 如 1 •… 

^VO\>CV"t»CS, "too. 



Almosi cvcvy-thi h g i h 
‘ 心 v gets pushed 

U P "to /hs-tvumcivt ； 3hd 

9 C ^ '^hevited. £o wc 
^ gc-t vid o( lois of 
"these pvopcviics ； as 

七 ― 3 C + ^oved i h -to -the 
lr\si\ru^eni base dlass. 
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good design = flexible software 


Wd you notice that abstract 
base class? 

Take a close look at the new Instrument class 
that we created: 


Instrument 

serialNumber: String 
price: double 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec ()： InstrumentSpec 


V\/e {jooV all 

avc towwow -to 
a^d Mav>dolm, 


Instrument is an abstract class: that means that you 
can’t create an instance of Instrument. You have 
to define subclasses of Instrument, like we did 
with Mandolin and Guitar: 


Instrument 


serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec ()： InstrumentSpec 



l^urhcirt is -the base 

“ /VUdoli 二 d 

-they base theiv 
bchaviov o-Pf of 

〆 


We made Instrument abstract because 
Instrument is just a placeholder for actual 
instruments like Guitar and Mandolin. An 
abstract class defines some basic behavior, but it’s 
really the subclasses of the abstract class that add the 
implementation of those behaviors. Instrument 
is just a generic class that stands in for your actual 
implementation classes. 


4 … m 釙 d /VUdoU 

7 卜士 ^ optics 

C，hCC * ，h i h 

wa f io a 

Ad ^hdolih. 


Abstract classes 
are piacekoiJers 
for actual 
implementation 
classes. 


Tke abstract 
class Jefines 
Lekavior, anct 
tke subclasses 
implement tkat 

Lekaviort 


you are here ► 
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adding a MandolinSpec 

Well need a MandolinSpec class, too 

Mandolins and guitars are similar, but there are just a few things 
different about mandolins... we can capture those differences in a 

MandolinSpec class: 


GuitarSpec 

builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 
numStrings: int 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
getNumStrings(): int 
matches(GuitarSpec): boolean 


MandolinSpec 


builder: Builder 
model: String 
type: Type 
Style: Style 
backWood: Wood 
topWood: Wood 
numStringo: iat - 


Alahdolms 
^on\t ih scvcv-al 

styles，like a〆％" 


getBuilder(): Builder 
getModel(): String 
getType(): Type 
getStylej): Style 
getBackWood(): Wood 
getTopWood(): Wood 
girtf'luinOliinfl^O' int 
matches(MandolinSpec): boolean 


Most ma^dol'ms 
Kavc ^ ?a'ivs 

Jc sbr ’《 呼 

(«-to-tal), so 

vuAwStv'mJs is 灼’七 

needed 


Just as y/C used 

fov* Wood 
Buildcv-, >wc 
dveate a _ *b/? c 

-(•ov ma^dolm s 切 l es . 


I 七 、 U You dU’U— af ” ^ 
.a,doUs, i ^ out H 

»s tKat you 一从 ^obablv ^ 
a\>sbrati tlass, all tKc better 1 



Those spec classes sure 
look a lot alike. How about we use 
an abstract base class here, too? 


嫌 




What do you think about this design? Will it do what the customer 
wants it to do? How flexible is it? Do you think software designed 
like this will be easy to extend and maintain? 
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good design = flexible software 



e no , 

Questions 


乂 . We made Instrument abstract because we abstracted the 
properties common to Guitar and Mandolin into it, right? 

A! No, we made instrument abstract because in Rick’s 
system right now, there’s no such thing as an actual “instrument.” All 
it does is provide a common place to store properties that exist in 
both the Guitar and Mandolin classes. But since an instrument 
currently has no behavior outside of its subclasses, it’s really just 
defining common attributes and properties that all instruments need 
to implement. 

So while we did abstract out the properties common to both 
instrument types, that doesn’t necessarily mean that instrument 
has to be abstract. In fact, we might later make instrument a 
concrete class, if that starts to make sense in our design... 


Couldn’t we do the same thing with GuitarSpec and 
MandolinSpec? It looks like they share a lot of common 
attributes and operations, just like Guitar and Mandolin. 


Good idea! We can create another abstract base class, 
called instrumentSpec, and then have GuitarSpec and 
MandolinSpec inherit from that base class: 


InstrumentSpec 

model: String 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 



GuitarSpec 


MandolinSpec 


numStrings: int 




“ getNumStrings(): int 
matches(GuitarSpec): boolean 


getStyle(): Style 

matches(MandolinSpec): boolean 





Ufs put everything together. 


you are here ► 
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abstracting common behavior 


Pehold: Rick's new application 

It looks like all that work on design back in Chapter 1 has paid off; 
it took us less than 10 pages to add support for mandolins to Rick’s 
search tool. Here’s the completed class diagram: 


Inventory 


adidi^u'rtav-0 b> addlns-tvumcn-tO. 


addlnstrument(String, double, InstrumentSpec) 

get(String): Instrument ^ - 

search(GuitarSpec): Guitar [*] 考 — 


search(MandolinSpec): Mandolin [*] 


inventory 


大 


tint’s a 於 

• ， - tal'id'izjcdi tlass 
mCdns m UML- 


serialNumber: String 
price: double 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 


No ” ei (l ^ 

…如 d just a $ 心 . 

Wc i\ttA *bwo scav-dV>0 
methods y\o>w ： oy\C 
-fov jui*tav-s and one 



wci1 


^uitav ar»d /Vlahdolih dot!i do a^y-tKih^ 

bu*t c^-tchd IhS-tvumCh-t. TKc di-ffcvchdcs 

between iKc -two -types o-f ihsivumchis 
ave cndapsulaicd away ih ilie sped dlasses. 
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good design = flexible software 


Wkenever you iinJi common tekavior in two 
or more places，took to abstract tkat tekavior 
into a class，anct tken reuse tkat tekavior in 
tke common classes. 


led -to 

abstvadt base Masses. 


No\N i\\t abstvatt |y\s*br_e>rvt 

dass is asso6a*ted v/i 七 h 

abs 七 vat 七 |jrvs*tv*uw»cw*tSpct dass 


/^umchiSpcd is associated 

all -the chumeva-ted £yp CJ 
七 we used 
diircrtly ih ^uiiavSpcd. 



GuitarSpec 


numStrings: int 


getNumStringsQ: int 
matches(GuitarSpec): boolean 


帅 ， S a” elevated tWt 

山 ss, sW 心 ^ 

w a,dolms, a,d -t all 
s—kaW 七 7? cs . 



後 咐 d "to ovcvHdc matdKcsO ih ca^K 

sped dlass -to Kar>dlc additional pvopcv-tics 
spedi-f id -fco t^C\) ihS'tvurxCh't. 


you are here ► 
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a little more uml 


Class diagrams dissected (again) 

Now that you’ve added abstract classes, 
subclasses, and a new kind of association, it’s time 
to upgrade your UML and class diagram skills. 



jrvamC o-f 3 
•is m vtalits, 七 tlass 
•IS abybra。 七 . ttcvc, >wc 
doY\ l i v/ay»*b anyone 
Crea 七 ” ms*b3v»d.cs 

o-f |ir»s*brume\rrb; its 
jus 七 used to provide 
3 C,on\n\oy\ bssc ^oV 
s^cd'i-f'»6 ms^brume 妁七 
classes, like ^u'rbav- 
dnd Ma^dol'm. 


dass 


This Ue WrtK a diamond wans a<yyreo^W. 

^yrt^aho^ is a special of association, a^a means 

i\,ai tKrnj is 你 ade 叶 （m favt) o( air>otV>cv 

So ktvumat is made u ? o-f \^sbr^t^tt. Mo^c iiaUs ： l^u^i£p e , 

、 is also abstwt. 


Instrument 


spec 


serialNumber: String 
price: double 


getSerialNumberQ: String 
getPriceQ: double 
setPrice(iloat) 
getSpecQ: InstrumentSpec 


InstrumentSpec 


model: String 



getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 


A I me with av\ a\rv-ow -that iWi 
to\oYtd ih mcaw jChClr^liz^tioh. / ou 
usc a 3Chciraliza-tioh -to show tha-t 
a dass (like Ala^dolih) cx-fecnds 
3hd bchaviov- a r^o^c 

gchcirali^d dlass Oikc l^sbru^i). 
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good design = flexible software 


fold 七 Vis do>wy» so you 

Yt^cc batk 七 o I 七 ⑶ 

you -fov-^ct some o( UML s 

y»0*t3t»0)r\ d 灼 d symbols. 



rWH CMf 孙 eef 


What wc call 

What wc call 

it iw Java 

it iw UML 

Abstract Class 

Abstract Class 

Relationship 

Association 

Inheritance 

Generalization 

Aggregation 

Aggregation 


How wc show 
itm UMl 

Italicized Class Name 





e no . 

Questions 


Are there lots more types of symbols and notations 
that I’m going to have to keep up with to use UML? 


A! There are a lot more symbols and notations in UML, but 
it’s up to you how many of them you use, let alone memorize. 
Many people use just the basics you’ve already learned, and 
are perfectly happy (as are their customers and managers). 

But other folks like to really get into UML, and use every 
trick in the UML toolbox. It’s really up to you; as long as you 
can communicate your design, you’ve used UML the way it’s 
intended. 


you are here ► 
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abstract classes and instruments 


Let's code Rick's wew search tool 


We can start off by creating a new class, Instrument, and making it 
abstract. Then we put all the properties common to an instrument in this class: 


public abstract class Instrument { 

»s afe 士 ra 冼…， 

private String serialNumber; *to ms-tav>t«3"tc subclasses 

private double price; ^ |S ^ asc tlass, like 

private InstrumentSpec spec; 

public Instrument(String serialNumber, double price, 

工 nstrumentSpec spec) { 个 

this. serialNumber = serialNumber; AA « ^ i. 

/Wost or -this is pv-etty 

simple ； olhd looks d lot 
like the old ^ui-feav- dlass 
wc had- 


this.price = price; 
this.spec = spec; 


// Get and set methods for serial number and price 


public 工 nstrumentSpec getSpec () 
return spec; 



l/Ve used iKc agjircjaiioh 
-fovm o( association bemuse 
|hS-t\rur»»Ch-t is made up 

o-f the scvial/Vumbcv- ahd 

p\ri 匕 e member variables ； a^d 

^ ihs-tahdc. 


Instrument 

serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpecQ: InstrumentSpec 


◊ 




InstrHient.java 


Next we need to rework Guitar. java, and create a class for mandolins. 
These both extend Instrument to get the common instrument properties, 
and then define their own constructors with the right type of spec class: 


All tacM 

•mstvuwC 灼七 
tlass r\ccds 
»s -bo ^ 

|r\sbruwC 此 _ 

a 矜 d \>v-ov'idc 
a d.or\stv-ut*tov- 

takes i\\t 
kmd of 
object- 


public class Mandolin extends Instrument 


public class Guitar extends Instrument 


public Guitar(String serialNumber, double price 

- GuitarSpec spec) { 


Number, double price, 

ec) { 

sg>ec); 


super(serialNumber, price , spec); 


Giltar.java 


Mandolin 



class 
Mandolin 

Mando- 
lin() } 



Mandolin.java 


Mandolm is almost id ⑶七 ieal 
-to 今 uitdv; i 七 jus*t -takes m S 
MadoU 巧 et’m 七 he toyvstvut-tov 
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good design = flexible software 


Create m abstract class for 
iwstrumcwt specifications 

With the instruments taken care of, we can move on to the spec 
classes. We need to create another abstract class, InstrumentSpec, 
since so many instruments have common specifications: 


public abstract class InstrumentSpec 


spec 1 


InstrumentSpec 


model: String 


getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentS 


InstrumentSpec.java 



rivate Builder builder 
rivate String model; 
rivate Type type; 
rivate Wood backWood; 
rivate Wood topWood; 


Jus*t like IhS-tvumCh-t, 

is abstvadt 
youll use subclasses -fov- 
eadh ihS-tv-umCht iype. 


ublic 工 nstrumentSpec(Builder builder, String model, Type type , 

Wood backWood, Wood topWood) { 
this.builder = builder; This is sir^ilav -fco ouv old 

this.model = model; dohsivud-fcov. 

this, type = type; ^\\ tA 

this .backWood = backWood;_ *" c ^ ' ^cs towwow 

{p all ms-tvuwC^-U, like 

// All the get methods for builder, model, type, etc. 


this.topWood = topWood; 


public boolean matches(InstrumentSpec otherSpec) 
if (builder != otherSpec.builder) 
return false; 

if ( (model ! = null) && (!model • equals ('、〃））&& 

(!model.equals(otherSpec.model))) 
return false; 

if (type != otherSpec.type) 
return false; 

= otherSpec.backWood) 


if (backWood !: 

return false 
if (topWood != 
return false 
return true; 


otherSpec.topWood) 


71) is 



“鳥 so 

Zil 〜 d 

suk/ ° Ve ^ ，dc ^ 

Sub ^ h 
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completing the spec classes 


Let's code ftuitarSpcc, 


With InstrumentSpec coded up, it’s pretty simple to write the 

Guitar Spec class: 


Jus 七 as ^uitav extended 
|y\s 七七 , ^ui*t3v*£^ct 
卜 s*brume>rv 七 Spet. 


public class GuitarSpec extends InstrumentSpec 

private int numStrings; 




public GuitarSpec(Builder builder, String model. Type type, 

int numStrings , Wood backWood, Wood topWood) 
super (builder, model, type^kWood, topWood); 

this . numStrings = numStrings ; 

} Tliis dohS-t\rud-tov just adds 

3ui-ta\r-spcdi-fid p^ofev-ties 

public int getNumStrings () { wKats already sWd ih 

} return numStrings; tKe base class. 


// Override the superclass matches() - - 

public boolean matches(InstrumentSpec otherSpec) {) 

if (!super.matches(otherSpec)) MtsO uses su ? c^lass 

return false; wa U^sO, ad 

if ( ! (otherSpec instanceof GuitarSpec) ) to wake 

return false; tic C s ? ct »s tV. C 

GuitarSpec spec = (GuitarSpec) otherSpec; ^ ^ ^u'»-ta 

if (numStrings != spec.numStrings) ^ - 

return false; 
return true; 


s 


suv-c ttc 

w3*b^cs *tVw 
^o\>cvt'»cs. 


f ^ a lot o( it behavi 

Wo ^ how, so the 

dodc W ^^-ta^ped has sliced 

dovm a lot 4o 眯 Chappy /. 


InstrumGntSpGC 


model: String 


getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 


GuitarSpec 


numStrings: int 


getNumStrings(): int 
matches(GuitarSpec): boolean 




GuitarSpec.java 
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•••ami MandolmSpec, too 

After seeing Guitar Spec, MandolinSpec is pretty simple. 
It’s very similar, with the addition of a member variable to 
reference the mandolin’s style (like “A” or “F” style), and a 
slightly different matches () method: 


public class MandolinSpec extends InstrumentSpec { 

_ma^dolms Kavc a Style, so \s 

private Style style; ? usKcd uf m*to base tlass. 

public MandolinSpec(Builder builder, String model, Type type, 

Style style, Wood backWood, Wood topWood) { 
super(builder, model, type, backWood, topWood); 
this.style = style; 

} 

public Style getStyle() { 

return style; 


// Override the superclass matches() 
public boolean matches(InstrumentSpec otherSpec) { 
if ( !super.matches(otherSpec)) 
return false; 

if (!(otherSpec instanceof MandolinSpec)) 



return false; 

MandolinSpec spec = (MandolinSpec)otherSpec; ^ 

if (!style.equals(spec.style)) 
return false; 

return true; 


vW like /W^doli^pcd 

uscs，ts s “P c wl 收 do b 把 id 

”扣如 d Usts {o 

^doli„£f> ed ar)d dorh p^ cs ihe 

^ ， doli^sp C di-Pid p，£ ics . 


MandolinSpec 


getStyle(): Style 

matches(MandolinSpec)^ boolean 


style 


public enum Style 

A, F; 





toStringQ: String 


V^>U II meed 3 
r\CY/ Chumcv*a*tcd 
Siylc. Use 
■bwo chumcvatcd 
values, A P. 


MandolinSpec.java 


Style.java 
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coding rick’s search tool 


Finishing up Rick's search tool 

All that’s left is to update the Inventory class to 
work with multiple instrument types, instead of just the 
Guitar class: 


public class Inventory 


private List inventory; 


TV>c mvcyv-tov*Y list «rvo>w holds 
multiple o-f ms*br_ ⑶ ts, 

no 七 jus 七 juitavs. 


Inventory 


inventory: Instrument [*] 


addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 
search(GuitarSpec): Guitar [*] 
search(MandolinSpec): Mandolin [*] 



■ ^ — 

Inventory.java 


public Inventory 。 { 

inventory = new LinkedList(); 

} 


By usihj -the /hS-tirumch-t 


add^ui-ta^rO ih-to 


a r^c-thod, 


ahd ^ C9ic o( 


public void addinstrument (String serialNumber, double price , 

InstrumentSpec spec )^1 - 

Instrument instrument = null; 
if (spec instanceof GuitarSpec) { 

instrument = new Guitar(serialNumber, price, (GuitarSpec)spec) 
} else if (spec instanceof MandolinSpec) { 

instrument = new Mandolin(serialNumber, price. 


inventory.add(instrument) 


public Instrument get(String serialNumber) { 

for (Iterator i = inventory.iterator(); i.hasNext(); ) { 

Instrument instrument = (Instrument)i.next(); 
if (instrument.getSerialNumber().equals(serialNumber)) 
return instrument; 

} Hcvcs a^o-tV^cv usmj 

} akstv-att base tlass makes ouv- 

return 而 11; dcs 吵 morc 


(MandolinSpec)spec); 

is absi^di a^d 

dah 七 \i dirtily, 

io do sor^c wo^k 


wc 

wc 


// search(GuitarSpec) works the same as before 

public List search(MandolinSpec searchSpec) { - 

List matchingMandolins = new LinkedList(); 
for (Iterator i = inventory.iterator(); i.hasNext(); ) { 
Mandolin mandolin = (Mandolin)i.next(); 
if (mandolin.getSpec().matches(searchSpec)) 
matchingMandolins.add(mandolin); 

} 

return matchingMandolins; 



M 3ho-thc\r scamdhO method 
■to handle mahdolms. 


A 七 *this poih*t/ y ouVc ready *to *bry ou*t 
Ridk^s improved aff. See i+ you cby\ updaic 
Pmd^ui*t«l\rTcs-tc\r oh you\r ovm, dhd see hoy/ 
avc y/ork'm^ y/i*tli *thcsc dcsi^h 
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e no , 

Questions 


Guitar and Mandolin only have a 
constructor. That seems sort of silly. Do 
we really need a subclass for each type of 
instrument just for that? 

We do, at least for now. Otherwise, 
how could you tell a mandolin from a 
guitar? There's no other way to figure out 
what type of instrument you’re working 
with than by checking the type of the class. 
Besides, those subclasses allow us to have 
constructors that ensure that the right type 
of spec is passed in. So you can’t create a 
Guitar, and pass a MandolinSpec 
into its constructor. 



But with Instrument as an abstract 
class, the addlnstrument() method in 
Inventory.java becomes a real pain! 

You’re talking about 
addinstrument () on page 212, 
aren’t you? Yes, with instrument as 
an abstract class, you do have some extra 
code to deal with. But it’s still a fairly small 
price to pay to ensure that you can’t create 
an instrument, which really doesn’t 
exist in the real world. 



TV^csc avc IvWJc 'md»6d-tov-s a ^ ,, 

a 1 二二 Y 

^Ve about ^ 



Isn’t there some middle ground, 
though? I mean, even if there’s no such 
thing as an “instrument” that isn’t a guitar 
or mandolin or whatever, it still seems 
like we must have a design problem 
somewhere. Right? 


A! Well, you may be onto something. 
It does seem like parts of our code would 
benefit from a concrete instrument 
class, while other parts wouldn't. 
Sometimes this means you have to make 
a decision one way or the other, and just 
accept the trade-off. But maybe there’s 
more going on here that we’re not thinking 
about... 




Why do we have two different 


versions of search()? Can’t we combine 
those into a single method that takes an 
InstrumentSpec? 


. Since InstrumentSpec is 
an abstract class, like instrument, 
Rick’s clients will have to give either a 
Guitar Spec or a MandolinSpec to 
the search () method in Inventory. 
And since a spec will match only other 
specs of the same instrument type, there's 
never a case where both mandolins and 
guitars would be returned in the list of 
matching instruments. So even if you 
consolidated the two search () methods 
into one, you wouldn’t get any functionality 
benefit—and even worse, it might look like 
the method would return both mandolins 
and guitars (since the return type of 
search () would be Instrument 
[*]), even though it never actually would. 
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major improvements 


O 


Wow, this is really starting to look 
pretty good! Using those abstract classes 
helped us avoid any duplicate code, and weve 
got instrument properties encapsulated 
away into our spec classes. 



You’ve made some MAJOR 
improvements to Rick’s app 

You’ve done a lot more than just 
add support for mandolins to Rick’s 
application. By abstracting common 
properties and behavior into the 

Instrument and InstrumentSpec 


classes, you’ve made the classes in 
Rick’s app more independent. That’s a 
significant improvement in his design. 



I don’t know... it seems like weve still 
got a few problems, like the almost- 
empty Guitar and Mandolin classes, 
and addlnstrument() with all that nasty 
instrument-specific code. Are we just 
supposed to ignore those? 


O 


O 


Great software isn 9 t 
built in a day 

Along with some major design 
improvements, we’ve uncovered a few 
problems with the search tool. That’s 
OK... you’re almost always going to find 
a few new problems when you make big 
changes to your design. 

So now our job is to take Rick’s better- 
designed application, and see if we can 
improve it even further... to take it from 
good software to GREAT software. 
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good design = flexible software 


3 steps to great software (revisited) 

Is Rick’s search tool great software? 

Remember the three things we talked about that you can do to write great 
software? Let’s review them to see how well we’ve done on the latest version 
of Rick’s search tool. 

1. Does the new search tool do what it’s supposed to do? 


2. Have you used solid 00 principles, like encapsulation, to avoid duplicate 
code and make your software easy to extend? 


3. How easy is it to reuse Rick’s application? Do changes to one part of the 
app force you to make lots of changes in other parts of the app? Is his 
software loosely coupled? 


口 r 
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is this great software? 



E 站 RciSd 


§PL|itlPHS 


Is Rick’s search tool great software? 

Remember the three things we talked about that you can do to write great 
software? Let’s review them to see how well we’ve done on the latest version 
of Rick’s search tool. 

1. Does the new search tool do what it’s supposed to do? 

Absolutely. It finds guitars and mandolin although not at the 

same time. So maybe it just mostly does what ifs supposed to 

do. better ask Rick to be sure... 


2. Have you used solid 00 principles, like encapsulation, to avoid duplicate 
code and make your software easy to extend? 

We used encapsulatiow when we came up with the liistrumewtSpec 

classes, and ihheritahee when we developed ah Iwstrument and 

IhstrumentSpec abstract superclass, gut it still takes a lot of work 

to add hew ihstrumeHttvpes... 


3. How easy is it to reuse Rick’s application? Do changes to one part of the 
app force you to make lots of changes in other parts of the app? Is his 
software loosely coupled? 



Ifs sort of hard to use just parts of Rick's application. Everything's 

pretty tightly cohhectci and IhstrumehtSpec is actually part of 

Instrument (remember when we talked about aggregation?). 


Its 0 ^ 7 0U ^ sowC 

V^ad d 淑 c …七 ideas 
>/c M oy\ t^ese 
just 

SUV-C 70U 七 Vu 呼 

*tV^3"b Y olA 

udcdaW 士/从 

a^s>wcv-cdi V>ov/ d»d- 
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good design = flexible software 


O 


Tm loving what you re doing to my 
search tool! As long as youre here, I think 
rd like to start carrying bass guitars, banjos, 
and dobros (you know, those guitars you play 
with a slide). And how about fiddles, too? 


Lc / S M Rid^ 





One of the best ways to see if software is 
well-designed is to try and CHANGE it. 

If your software is hard to change, there’s 
probably something you can improve about the 
design. Let’s see how hard it is to add a couple 
of new instruments to Rick’s app: 



\A/cll -to Aa 哼 

add ov c 

W •«▲ 一七切 ? cs . No 七 

a olcasa^t 


t ^t\\ mstvuw 忧 t 切 ? c . 



^ced -pouv hcv 
sped objed^ts, "too, 
eadh one addihg 
•"fes oy/h set of 
•hs-tvurif»civt-spc^i-pi 
properties. 
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change is hard 

Uh oh... adding new mstrumcwts is wot easy! 

If ease of change is how we determine if our software is 
well-designed, then we’ve got some real issues here. Every 
time we need to add a new instrument, we have to add 
another subclass of Instrument: 


Instrument 


serialNumber: String 
price: double 
spec: InstrumentSpec 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 


<} 



Y ou 七 U about 

se ||' m ^ a tlass -fov- catVi mstvumc^t 
is a little ⑽ 7. 


Then, we need a new subclass of 

InstrumentSpec, too: 


InstrumentSpec 

model: String 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 




BanjoSpec 


numStrings: int 


getNumStrings(): int 
matches(BanjoSpec): boolea 



MW io have 

一 Code hem., 

bahjos have a 

Jopc^y |ik c guibv-s, but 
•七 s not 3 domrhoh Choujh 
^ofc\riy -to move ih-fco |hc 
l^tlrurhcirt supev^bss. 


Then things start to really get nasty when you 
have to update the Inventory class’s methods to 
support the new instrument type: 


| Inventory 



inventory: Instrument [*] 


一 

addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 
search(GuitarSpec): Guitar [*] 
search(MandolinSpec): Mandolin [*] 

search(BanjoSpec): Banjo [*] - - 








Rcmcrwbcv- all 

•m addks-tv-umc^tO? It 
yts >wovsc cvcvy ^ 

•msbrur^ 七 切产⑽ suft. 

丁 h sca\rdKO si-tuatioh is 
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good design = flexible software 



So what arc wc supposed to do wow? 

It looks like we’ve definitely still got some work to do to turn 
Rick’s application into great software that’s truly easy to change 
and extend. But that doesn’t mean the work you’ve done isn’t 
important... lots of times, you’ve got to improve your design 
to find some problems that weren’t so apparent earlier 
on. Now that we’ve applied some of our OO 
principles to Rick’s search tool, we’ve been 

• ■ ■ It 、 一 :* 

able to locate some issues that we’re going 
to have to resolve if we don’t want to spend 
the next few years writing new Banjo and Fiddle 
classes (and who really wants to do that?). 


、 import 

^ tofl: 

class 

Before you’re ready to really tackle the next phase of 
Rick’s app, though, there are a few things you need to 
know about. So, without further ado, let’s take a quick 
■ break from Rick’s software, and tune in to... 

If* 


M MTABTRDPUE! 


Objectvill-e's Favorite Quiz Show 
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Objectvilie's Favorite Quiz Show 















































o 


Weve got some great 00 categories 
today, so lefs get started. Remember, 
ril read off an answer, and \fs your job to 
come up with the question that matches the 
answer. Good luck! 



A. 

It might not seem like it, but we are working on Rick’s 
search tool, in a manner of speaking. We’re going to need some 
pretty advanced 00 techniques to make his application flexible and 
reusable, and we wanted to give you a chance to get a handle on 
these principles before you had to start applying them to a pretty 
complicated problem. 


A. 

The questions that match up with the answers in this chapter 
aren’t easy, but you should be able to reason them all out. Take 
your time; it’s important that you come up with these questions on 
your own if at all possible, and only then turn the page to get a little 
more information on each question and the 00 principle it involves. 
Besides, we think you’re getting to be a pretty kick-ass developer, so 
we have lots of confidence in you. 


! Why are we playing a game show? Shouldn’t we be 
fixing Rick’s search tool? 



If these are new 00 principles, how am I supposed to 
figure out what the questions are? That’s asking a lot, isn’t it? 
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BB MTUTMPUE! 

Objectvilie's Favorite Quiz Show 
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"What is an INTERFACE? 


扣 swem 0h p a ^ e 2ZB. C 


Suppose you’ve got an application that has an interface, and then lots 
of subclasses that inherit common behavior from that interface: 


壯 Wctc dc-f'mcs a - 
^la^O method 七七 
all classes 

灼七 … s^>ov-*t- 

邛 … a ， 


《 interface 》 
Athlete 

getSport(): String 
P'9y() 







Anytime you’re writing code that interacts with these classes, you have 
two choices. You can write code that interacts directly with a subclass, 
like FootballPlayer, or you can write code that interacts with the 
interface, Athlete. When you run into a choice like this, you should 
always favor coding to the interface，not the implementation. 


_ 七 type sKould 
"tliis »v»c-feKod -feakc? 



Why is this so important? Because it adds flexibility to your app. 
Instead of your code being able to work with only one specific 
subclass — like BaseballPlayer — you’re able to work with 
the more generic Athlete. That means that your code will 
work with any subclass of Athlete, like HockeyPlayer or 
Tennis Player ， and even subclasses that haven’t even been 
designed yet (anyone for CricketPlayer?). 


Cocting to an 
interface, ratker 
tkan to an 
implementation^ 
makes your 
software easier 
to extend. 


By cocting to 
an interface ， 
your code will 
work witk all oi 


tke interface’s 
subclasses—even 
ones tkat 
kaven’t teen 


createJ yet. 
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It’s been responsible for 
preventing more maintenance 
problems than any other 
00 principle in history，by 
localizing the changes 
required for the behavior of 

object to vary. 


"What is 
























































'What is ENCAPSULATION ?" 

We’ve talked a fair bit about encapsulation already, in terms of 
preventing duplicate code. But there’s more to encapsulation than 
just avoiding lots of copy-and-paste. Encapsulation also helps you 

protect your classes from unnecessary changes. 


Anytime you have behavior in an application that you think is likely 
to change, you want to move that behavior away from parts of your 
application that probably won’t change very frequently. In other 
words, you should always try to encapsulate what varies. 


Neve’s a 叫 
sm^\t tlass 
does tWrcc 认呼 : 
Yvcyavcs a v'C'w 
edsel ； t\t^s 



^ «s C | a hC | 
^Icahihj brushes Svc 

9 oih 9 也 y pretty 

the sa^c. 


avc 


gut Wat about pamtma? TKc style of 
? amtm5 vanes... ttc Wus^cs av 

used vavics... CVC^ i\\t s^ttd at 

odtuvs vav'ics. £0 V\cvc s ^cv-c a 

七 Vie tould ^ Pamtcv-- 


It looks like Painter has two methods that are pretty stable, but 
that paint () method is going to vary a lot in its implementation. 
So let’s encapsulate what varies, and move the implementation of 
how a painter paints out of the Painter class. 


Raih-t£-ty| c vcpvcsch-ts -th 
paid behavior. 


t 


Wic’ve 

cv\6a\>sula-tcd 
4a 七 vav'ics--t^c 
bcV^av'iov- 

out "tVic 
Pa'mtcv- tlass. 
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Every class should attempt to 
make sure that it has only one 
reason to do this，the death of 
many a badly designed piece 

of software. 
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What is CHANGE? 


You already know that the one constant in software is 
CHANGE. Software that isn’t well-designed falls apart at the 
first sign of change, but great software can change easily. 


The easiest way to make your software resilient to change is 
to make sure each class has only one reason to change. 

In other words, you’re minimizing the chances that a class is 
going to have to change by reducing the number of things in 
that class that can cause it to change. 


Take a look at tKc 
methods m tWis dass. 

TV^CY deal ^ 

a 灼 d “ 七 , ' ^ 

av-c — a 

dyWcv div*Wcs *bV>c 63 V - , 
y/asWmJ tS'C) cvcvx 

Oil 




start() 

stop() 

changeTires(Tire [*]) 

drive() 

wash() 

checkOil() 

getOilQ: int 


^ tU9s ^ 
f； uld ^ -to 如， 

: 扎， how J 

^ks ihe oil, o^r Ld …汴 

… di^ii 

sh is wdcd/ 

iLs 6odc w，11 io dhah 9 c. 


When you see a class that has more than one reason to 
change, it is probably trying to do too many things. See 
if you can break up the functionality into multiple classes, 
where each individual class does only one thing — and 

therefore has only one reason to change. 

^ 心， k hdo>st 

A t ... ■ ，— L so have 

Automobile ■ b> ^]y as ^ 



a L£T s W? l 
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七 V\c (\Ar\thor\3\\bl 
a m-to *Uo 

bcV^aviov classes. 
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you’ve been doing pretty well, but 
now ifs time for FINAL CATASTROPHE. 

Below is the class diagram for an application thafs 
not very flexible. To show that you really can avoid an 
00 catastrophe, you need to write down how you’d 
change this design. You’ll need to use all the principles 
we’ve been talking about, so take your time, and 

good luck! 


TKTMPU 



DessertCounter 

orderCone(lceCream[*], Topping!*]): Cone 
orderSundae(lceCream[*], Topping!*], Syrup[*]): Sundae 
addTopping(Cone, Topping): Cone 
addTopping(Sundae, Topping): Sundae 


Sundae 


iceCream: IceCream [*] 
syrups: Syrup [*] 
toppings: Topping [*] 


addlceCream(lceCream) 

addSyrup(Syrup) 

addTopping(Topping) 

serve() 


Cone 


iceCream: IceCream [*] 
toppings: Topping [*] 


addScoop(lceCream) 

addTopping(Topping) 

serve() 



Topping 


description: String 


getDescriptionf): String 
serve() 


IceCream 


taste: String 

getTastef): String 
serve() 



Syrup 


ingredients: String [*] 


getlngredientsQ: String [*] 
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^«sc^Couhtc<r is dodir>a ^ 
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^Answers 


DessertCounter 


orderCone(lceCream[*], Topping^]): Cone 
orderSundae(lceCream[*], Topping!*], Syrup[*]): Sundae 
addTopping(Cone, Topping): Cone 
addTopping(Sundae, Topping): Sundae 



Dcsscr-tCouh-tcir has move -thah 

° hC ^^soh -to dKahjc ： i-f -the 

,°^ c ； ih 9 how 

the Cohc and Sundae dlass adds 

VP— 如， . Addi ， 9 a ^opp ih a 
should be dohe io the Dcsscvt 
d * asscs diircd-tly ; h o-t Kcvc. 


is aw 

To^p'mj - >wc vcally , 
do 朽’七 yveed a method ■ 
spcti-fitdllY "to Sdd 3 
"Ti>W’nr^. Tha 七 s todi^ 

-to ayv iw^ltw»€>rv*tatio 灼 . 


iceCream: IceCream [*] 
syrups: Syrup [*] 
toppings: Topping [*] 


addlceCream(lceCream) 
addSyrup(Syrup) 
addTopping(Topping) 
serve() 


iceCream: IceCream [*] 
toppings: Topping [*] 


addScoop(lceCream) 

addTopping(Topping) 

serve() 



D 


there are* no 

umb Answers 


arc a LOT o( 妙 ve() 
i m? lcmc^tat.ons ^loatmj around. lA/c should 
i r y a^d c^6a\>sula-tc 4a 七 vav-ics, a^d fut 
all sc^rvmj todt rn one \>Ue’ T^at >way, 

iJp scv-Vmj \>^o6css Aav^es, y/c do 的 t 

^ttd -to At-t- ttese classes. 


A! You’ve seen several times already that when you see a 
potential for duplicate code, you should look to encapsulate. In this 
case, it’s reasonable to assume that serving a Sundae probably 
isn’t that different from serving a Cone. 

So you could create a new class, called DessertService, 
and put the serve () method in that class. Then, all of your 
Dessert, IceCream, and Topping classes could simply refer 
to DessertService. serve (). If serve () changes, you’ve 
got to update code in only one place: DessertService. 


So you’re encapsulating what might vary—the code in the 
serve () method—and you’re making sure that each class has 
only a single reason to change. That’s a double win! 

How did you know to encapsulate the serve() methods 
out of all those different classes? I missed that. 
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IceCream 

taste: String 

getTaste(): String 
serve() 




Syrup 


ingredients: String [*] 

getlngredients(): String [*] 
serve() 
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back to rick’s search tool 



O 


Ifs been great having you as 
a contestant, and wed love to have 
you back next week, but we just received 
an urgent call from a ''Rick"? Something 
about getting back to work on his 
search tool? 


You’re ready to tackle 
Rick’s inflexible code now 

With a few new OO tools and techniques 
under your belt, you’re definitely ready to 
go back to Rick’s software, and make it a 
lot more flexible. By the time you’re done, 
you’ll have used everything you’ve just 
learned on 00 Catastrophe, and made it 
easy to change Rick’s application, too. 


00 P\rihdiples 

v/ha 七 vavics. 

Code -to v-a-tlicv- ihavy -to av\ 

EaA dass m youv should liavc o^ly 

OY\t vcasoirv *to dlldirv^c- 
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5 (part 2) good design = flexible software 


Give Your Software a 
30-minute Workout 



Ever wished you were just a bit more flexible? 


When you run into problems making changes to your application, it 


probably means that your software needs to be more flexible and 


resilient. To help stretch your application out, you’re going to do some 
analysis, a whole lot of design, and learn how 00 principles can really 
loosen up your application. And for the grand finale, you’ll see how 
higher cohesion can really help your coupling. Sound interesting? Turn 
the page, and let’s get back to fixing that inflexible application. 


this is (sort of) a new chapter 
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problems with rick’s search tool 


Pack to Rick's search tool 

Loaded up with some new OO principles, we’re ready to tackle making 
Rick’s application well-designed and flexible. Here’s where we left off, 
and some of the problems we’ve discovered: 



addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 
search(GuitarSpec): Guitar [*] 
search(MandolinSpec): Mandolin [*] ^ 


inventory 


火 


Instrument 


serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 


秦 W 鼻义匕 
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examining the searchQ method 


O 


Guys, I’ve been looking over 
this class diagram for Ricks 
application, and there's just got to 
be a better way to deal with this 
search() method thing. 



Frank: Yeah, it’s a pain, but I don’t see any way to get around 
it. We have to let Rick’s clients search for each different type 
of instrument somehow. 

Jim: I still don’t see why we can’t have just one searchf) 
method that takes in an InstrumentSpec. Wouldn’t that cut 
down on all those different versions of searchO? 

Joe: Well, it would, but we still don’t have any way to 
return multiple types of instruments. If the client provides 
a GuitarSpec, it’s never going to match a BanjoSpec or 
MandolinSpec. So the list returned from searchQ will always 


have only the type of instrument that the client’s spec is for. 


Jim: Because we can’t instantiate InstrumentSpec, right? It’s 
an abstract class, so we have to create a MandolinSpec, or a 
BanjoSpec, or whatever. 


Frank: So maybe that’s the problem... besides, shouldn’t 
we be coding to an interface like InstrumentSpec, not an 
implementation like GuitarSpec or BanjoSpec? 

Joe: Hmmm. I hadn’t thought about that, but you’re right; 
we really should be focusing on the interface, and not all those 
implementation classes. 
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A closer look at the searchO method 

It seems pretty clear that there’s a problem with the way we’re handling 
searches for Rick’s clients. We could make Instrument Spec a 
concrete class, but would that solve all our problems? 



h. (GuitajrS. 


searc. 



search(BanioSpec) 


search(FiddleSpec) 




a 


Inventory.java 



StdXt I J^njoc. ^ 
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(^InstrumentSpec^) 

model: String 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 



Kow wc tavs let Ridk^s 
pass ih dh Ihstvur^rrtSped "to 
■felic sca^KO mciKod. 


Inventory.java 


you are here ► 


237 





































moving to a non-abstract InstrumentSpec 


The benefits of our analysis 

Let’s take what we’ve figured out about turning 
InstrumentSpec into a concrete class, and see if it makes 
the design of Inventory any better. 


public class Inventory { 

private List inventory; 

public Inventory 。 { 

inventory = new LinkedList(); 


Inventory 


inventory: Instrument [*] 


addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 

search(lnstrumentSpec): Instrument [*] 



Wcv-c s the bi 9 dhdhje 
that this pa 9c hijhlijhis. 



Inventory.java 



public void addlnstrument(String serialNumber, double price 

InstrumentSpec spec) { 

Instrument instrument = null; 
if (spec instanceof GuitarSpec) { 

instrument = new Guitar ( serialNumber, price, (GuitarSpec)spec) 

} else if (spec instanceof MandolinSpec) { 

instrument = new Mandolin(serialNumber, price, (MandolinSpec)spec); 


Wc still have some 
•issues V>cvc … tWlS 
wC jets 

a 灼 d wove 

to^\\tabtd cve” 

tiwc xc ddd a 的€叫 

切 ? c of 


◊ 


inventory.add(instrument); 





public Instrument get(String serialNumber) { 

for (Iterator i = inventory.iterator(); i.hasNext(); ) { 

Instrument instrument = (Instrument)i.next(); 
if (instrument.getSerialNumber().equals(serialNumber)) 
return instrument; 

} 

} 

return null; 



二 ” hO is looki 吒， 
ah i hS ^urh C h-t£pcd how. 


public List search (InstrumentSpec searchSpec) { 

List matchinglnstruments = new LinkedList(); 
for (Iterator i = inventory.iterator (); i.hasNext() 
Instrument instrument = (Instrument) i.next(); 
if (instrument.getSpec().matches(searchSpec)) 
matchinglnstruments.add (instrument); 



Y\OYI, 


return matchinglnstruments; 


lA/cVe tod'mj bo tVic base 

Masses like ad 

Ma^dolm- TW,s is a mudK better dc_. 




0y\ "top o( bc*t*tc\r design hoy/ scav^KO 
^ V-ciuVh dll ihsiv-umChts iKai 
evch i*f iKai lisi doirtaihs di-f^cvchi 
"types o-f ihS"t\rumCh'ts > like 七 v/o ^ui*t3\rs 
ohC mdhdolih. 
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good design = flexible software 


One of these things is not like the other... 

or is 

The search() method isn’t the only thing that makes adding new 
instruments to Rick’s application difficult. You also have to add a new 
subclass of Instrument for each new instrument type. But why? Let’s do a 
little more analysis. 

Why is there a need for an Instrument class in Rick’s application? 


t? 



arpen your pencil 


What things are common to all instruments? 


What things are different between instruments? 


If you have any ideas for how you might change Rick’s application so that 
you don’t need all the instrument-specific subclasses, mark those changes 
on the class diagram below. Feel free to add or remove classes and 
properties; it’s up to you to decide how you can improve Rick’s design. 
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resistance to change 


One of these things is not like the other... 

or is it" 



arpen your pencil 

answers 


The search() method isn’t the only thing that makes adding new 
instruments to Rick’s application difficult. You also have to add a new 
subclass of Instrument for each new instrument type. But why? Let’s do a 
little more analysis. 

Why is there a need for an Instrument class in Rick’s application? 

Most ihstrumewts have at least a few common properties, like serial 



you ^ccd *to 
>wv-'i-bc 

v/c d.d, but 70U 
should be 吒 aloy>5 
七 V>c sawc I'mcs V^cv-c- 





number and price. Instrument stores the common properties, and then 

each specific instrument type can extend from lustrumewt. 


What things are common to all instruments? 

The serial numbet ： the price, and some set of specifications 

(even though the details of those specs maybe different 

for different ihstrument types). 


What things are different between instruments? 

The specifications: each type of ihstrument has a different set of 


properties that it cam contain. And since each instrument has a 


different IwstrumentSpec, each has a different constructor: 


If you have any ideas for how you might change Rick’s application so that 
you don’t need all the instrument-specific subclasses, mark those changes 


on the class diagram below. Feel free to add or remove classes and 
properties; it’s up to you how you can improve Rick’s design. 
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good design = flexible software 


A closer look at the 
iwstrumewt classes 


Even though search () is looking better, there are still some 
real problems with all the instrument subclasses, and the 

addinstrument () method in Inventory. 

Remember, we originally made Instrument abstract because 
each instrument type was represented by its own subclass: 


Instrument 

serialNumber: String 
price: double 
spec: InstrumentSpec 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 


丁 |y\str ， 忧七山 SS 


ihstirumch-t subdlass jusi adds 

a -to that 

type s sped class. 


public class Mandblin extends Instrument { 

public MandolinC^trinq serialNumber^ double price, 


public class Guitar exte] 



ds Instrument 


3C 


Banjo 


I Guitar 

i Bas 


)lic Guitar(String ^erialNumber, double price , 

C<5uitarSpec spec^ { 
ui>er (serialNumber, price , spec); 




Mandolin.java 


Guitar.java 


Put classes arc really about behavior! 

But the reason you usually create a subclass is because the 
behavior of the subclass is different than the superclass. In Rick’s 
application, is the behavior of a Guitar different than that of an 
Instrument? Does it function differently in his application than a 

Mandolin or Banjo? 
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behavior or properties? 


O 


Q 



Guitar and Mandolin and 
the other instruments don’t 
have different behavior. But they have 
different properties... so we have to 
have subclasses for each instrument, 

right? 



r 


TWis is a ^ood 00 c, 

Wt vt s tausm ^ 

^cada^cs ^ a'' ^ 
subclasses. Well tor,t batk 

-to -tw»s O^t m a 


All the instruments — at least from Rick’s 
perspective — behave the same. So that leaves 
only two reasons to have subclasses for each 
instrument type: 

1. Because the Instrument class represents 
a concept, and not an actual object, it really 
should be abstract. So we have to have 
subclasses for each instrument type. 

2. Each different type of instrument has 
different properties, and uses a different 
subclass of InstrumentSpec, so we need 
an instrument-specific constructor for each 
type of instrument. 

These seem like pretty good reasons (well, at 
least the first one does), but we’re ending up 
with lots of extra classes that don’t do much... 
and that makes our software inflexible and 
difficult to change. So what do we do? 


|“ e … ⑽ M a 

參 …“ n 广 

plutkO, strumO, or 


丁 Wis looks like 扣 
tasc v/iicv-c v/cVc tod'mj 

{jo implementation 
•ms 七 ead 扣 mtcv-fatc. 

So 七 Wis is/ 七 a Jood 
vc3soy» bo kcc? 
|ns*bvumcy\*b abs*brat 七， 


Smtc 祕、 a?? 

already dots —at 

\i "to 

(咖 I), 

rcadi^ ^ ^ 

w akc W»s 

wore 


Remember the second step in 
writing great software，from 
back in Chapter 1: 

Apply basic 00 

principles to 
adet flexibility. 


. :: D we % ‘ 

tep ^ app/y ^ ^ 
-flhd ^ 0 lC ^ 5 WC ^ 
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good design = flexible software 


iarpen your pencil - 

、 Object-Oriented Principles to the rescue! 

There’s definitely a problem with Rick’s app, but we’re not sure what it is. When you 
don’t know what to do to solve a design problem, just run through the 00 principles 
you know, and see if any of them might help improve your software’s design. 

For each principle, check the box if you think it could help us out. Then, if you checked 
the box for a principle, it's up to you to write down how you could use that principle to 
improve Rick’s search tool design. 


|f||lnheritance 



Polymorphism 



bstraction 



Encapsulation 


► See wiatwe Aou^ri; on the next pa^e. 
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sharpen solutions 


e Jharpen your pencil - 

、、 answers 

Object-Oriented Principles to the rescue! 

There’s definitely a problem with Rick’s app, but we’re not sure what it is. When you 
don’t know what to do to solve a design problem, just run through the 00 principles 
you know, and see if any of them might help improve your software’s design. 



Inheritance 


|[3^Polymorphism 


^|a bstractio 门 


||R^Encapsulation 


WeVe usiwg inheritance already with the Instrument and lnstrumentSpec 

classes, and their subclasses, gut it does seem like the ihstrument-specific 

subclasses don't actually do anything but inherit from Instrument... they just 

have slightly different constructors. 


We use polymorphism in the search!) method to treat all instruments as 

ihstances of Instrument instead of worrying about whether they Ve a Guitar 

or a Mandolin. So searching is a lot easier:., but it would be nice to be able to 
use this in addlhstrumehttj too, and cut down (m some repetitive code. 

IhstrumeiitSpec abstracts the details about each instruments specifications 

away from the Instrument class itself, so that we can add new instrument 

properties without affecting the basic Iwstnmiejit class. 


WeVe using encapsulation a lot but maybe we can use it even more..._ 

remember, encapsulate what varies! Since the properties in each instrumewt 
type are what varies, can we somehow encapsulate those properties away 
from Instrument and IwstrumewtSpec completely? 
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good design = flexible software 


Us-tv-umCr\*b 
Wm •，恤 s 
a 呼 wove; vts a 

to^cctk.t tlass. 


Guys, weve been using 
inheritance, polymorphism, and 
abstraction in this design. But I’m beginning 
to think the key is encapsulation. Remember 
what we learned about separating what 
changes from what stays the same? 


Joe: Yeah, you’re talking about encapsulating what varies, right? 

Frank: Exactly! And we know that the properties for each 
instrument are what varies in the application. 

Jim: I thought we’d been over this; that’s why we have all those 
subclasses of Instrument, like Guitar and Mandolin. So we can 
represent the differences between each instrument. 

Frank: But that really didn’t help... and besides, the behavior of each 
instrument doesn’t vary, so do we really need subclasses for each 
one? 

Joe: So you’re saying we would make Instrument a concrete class, 
instead of being abstract, right? And then we can get rid of all those 
instrument-specific subclasses. 

Jim: But... I’m totally confused. What about the properties that 
vary across each instrument? 

Frank: What about them? The Instrument class has a reference to 
an InstrumentSpec, and all the property differences can be handled 
by those classes. Look: 

Wic v^dde |y\s-t\rumcy\*tSpct 
y»oy\-abs-tv*at*t> *too. 



^ dually 
thc 〉 

^ h c 11 

A 


Instrument 


serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 



spec 


s ireally MO «rea So *, h ave 

㈣ 


InstrumentSpec 


builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 


getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 


GuitarSpec 


numStrings: int 


getNumStrings(): int 
matches(GuitarSpec): boolean 




MandolinSpec 


getStyle(): Style 

matches(MandolinSpec): boolean 
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letting bad design die 


Pcath of a design (decision) 

One of the hardest things you will ever do is to let 
go of mistakes you made in your own designs. In Rick’s 
search tool, it doesn’t make sense to have separate 
Instrument subclasses for each type of instrument. 
But it took us almost 30 pages (and 2 parts of Chapter 
5) to figure that out. Why? 

Because it seemed to make sense at the 
time, and it’s HARD to change something 
you thought was already working! 



Code once, look twice (or more!) 


Keep looking over your designs when 
you run into problems. A decision 
you made earlier may be what’s 
causing you headaches now. 


It’s easy to rip apart someone else’s code, but you’ve 
got to learn to look at your own code, and identify 
problems. This is also where peer review, having fellow 
programmers look at your code, can really be a lifesaver. 
Don’t worry if you have to make changes; a better- 
designed application will save you tons of time in the 
long run. 

Design is iterative … and you have to be 
willing to change your own designs, as 
well as those that you inherit from other 
programmers. 



Pride kills good design 

Never be afraid to examine 
your own design decisions, 
and improve on them, even if 
it means backtracking. 




Let's kill ouv bad Ats^ \p 

trtait subd 'f SCS 

ov\tt a^d all, jet oy\ vm 

一七 ” yrtai a—• 
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good design = flexible software 


Let’s turw some bad design 
decisions into good ones 

Let’s kill all those instrument-specific subclasses: 


|於 七 yurwC 灼七 •咖七 
abstv-adt a^mov-c 


Instrument 


serialNumber: String 
price: double 
spec: InstrumentSpec 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 



six .. 

oui ^ ih< 

^losses f OY . j / 办 y new 

y des ^ ^C e it/ hai R>ik 



We also probably need a new property in each 
instrument to let us know what type of instrument it is: 



2 ， pu*t va | ues jh 一 |jk 

咖陳 咖 M mNVOLIN 

扣 d so o h . / ,,' 

Classes ^ 


0 



This is a huge improvement... but 
it still seems like adding a new spec 
class for every instrument type is 
pretty inflexible. 
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encapsulate what varies 


Om more cubicle conversation 
(and some help from Jill) 


I hate to butt in, but Ive 
been thinking about something 
you said earlier, Joe ： Encapsulate 

what varies. 


O 



J-,irs be 伙 listcknr^ rn o” 

some ideas emhowto 

»w^v-ovc a^> 


Joe ： But we just did that... we made Instrument concrete, and 
got rid of all the instrument-specific subclasses. 

Jill: Actually, I think that’s really only the first step. What 
really varies in Rick’s software? 



What varies in Rick's app? 


what 

you -thihk 

• - vav-ics ih 

"these bldhks. 


Frank: We’ve gone through this already: the properties for 
each instrument are what vary. 

Jill ： So can we encapsulate them somehow? 

Joe: We already have: we used the InstrumentSpec class for 
that. 


Frank: Wait a second, Joe. We used InstrumentSpec because 
those properties were used by both clients and instruments. So 
that was more about duplicate code... 

Jill: Yes! That’s my point... the properties inside 
InstrumentSpec vary, too. So maybe we need to add another 
layer of encapsulation. 

Joe ： So since the properties of each instrument vary, we 
should pull those out of InstrumentSpec? It’s almost like 
double-encapsulation or something. 

Jill ： Sort of... we encapsulate the specifications common 
across client requests and instruments from the Instrument 
class, and then we encapsulate the properties that vary from 
the InstrumentSpec class. 
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good design = flexible software 


"Poublc encapsulation" m Rick's software 

Let’s look at the layer of encapsulation we already 
have, and then see how we can add a little more 
encapsulation to get those properties that vary out of the 

Ins trumentSpec class. 


Instrument 


serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 


spec 


7^ usc ^ m tlass， 



InstrumentSpec 

builder: Builder 
model: String 
type: Type 
backWood: Wood 
topWood: Wood 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 


⑹ I • 似 “ Chapter / iKat d\^is 

Ad ihsilrumch-ts botK needed io use 
P^opcirtics, so WC tYtaitd tKc 

dlass io absi^rsd iKcm 
away -f\rom -feKc |hs*tirui^eia 七 ^lass. 


The ^>voWcw\ is tKat *t^esc 
^vo^cv-tics vav^ across, 

ar\d so 从代 

V,avm 5 ^ add a subclass U 
caA mstvumc^t 


Since some of these properties vary, we want to move 
them out of the InstrumentSpec class. We need a way 
to refer to properties and their values, but not have those 
properties hardcoded into the InstrumentSpec class. 
Any ideas for how we could do that? 

What type(s) do you think you could use to 
represent properties and access their values, 
but not have to change your InstrumentSpec 
class to support new properties? 


By encapsulating 


varies ， 


wkat 
you make your 
application more 
: flexible，and 
easier to dkange. 
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simple solutions rock 


ftettmg dynamic with 
iwstrumcwt properties 


What did you come up with on the last page to store 
properties? We decided that using a Map would be a great 
way to handle various types of properties, and still be able 
to easily add new properties at any time: 


InstrumentSpec 



<7 


properties: Map 

teuildofr Builder 


七 aekW _ d i Wood 

topW-e-ed: Wo-ed 


getProperty(String): Object 
getProperties(): Map 

gotBuildor(): B u il dor 

gotTypo(): Type 
get&ackWooelf)! Wood 

gjotTopWooel^): Wood 
matches(lnstrumentSpec): boolean 


V 


a Ma? 

S . 

yt v-'»d o( all 

^csc \>v-o\>cv-t'»cs (ar\d tV^c 

elated methods), ar»d 
)U st use ?vo^t«cs 
w a\> cv^/tWm 汐 


usc 3dpH ； y 0io 

^ ^illjusi ask ^ 

PteCd ^ 4od. 


"this pvopc^'ty 
■to tell us wha-t kihd of 
ihst\rumch-fe wcVc lookihj at 


Even better，now we can dump all those 
InstrumentSpec subclasses! 


GuitarSpec 


numStrir^^jJ^^ 

getN]jflrarings()^ 
^rf^hestGuitarSpecpxiglean 



T\\t only reason 

y^lt iidd ttese 
/ subclasses o-f 

I 灼 sbru 州⑶ •tSpt >was 

-to \\ar\d\t additional 

mS*bvumC)r»*b —16 
^V-OfCV-tlCS. 



^ ^ -Lake any f^o^hes 

， 7 e subclasses, 

^jusUdd ih 铋仏 e 

…外 ih /hS*tv-u>hCirtSpcd. 
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good design = flexible software 


What wc did: a closer look 

Anytime you see something that varies, you should look for 
a way to encapsulate. In the case of InstrumentSpec, 
we realized that the properties of an instrument vary. 


心 ow Usbruwcrvb because 

d • 饮七 s 孙 





InstrumentSpec 

class 


We W all ihc piropcv-£ics ; 
v/kh vary across 

a^d 

% CS > ^ pulled iher, out 


Pull out what varies 


W ° W 911 ^ P^-ti cs a , c 
二 P 吻士 d by ,a. c / va | uc 

P ,h a ~ 祕 sW^e 



Wken you ltave a set ol properties tkat vary 
across your objects，use a collection，like a Map ， 
to store tkose properties ctynamicall 》 


You’ll remove lots ol metkocts irom your classes, 
and avoid having to ckange your cocte wken 
new properties are actcted to your app« 
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using Instrument and InstrumentSpec 


Using the new Iwstrumcwt and 
IwstrumcwtSpcc classes 


Let’s take one last look at how our new Instrument 
and InstrumentSpec classes work in practice. Here’s 
where we are with the design right now: 


Instrument 


serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec ()： Instruments 


spec 




InstrumentSpec 


properties: Map 


getProperty(String): Object 
getProperties(): Map 
matches(lnstrumentSpec): boolean 


BotK |yvs 七 vumew 七 and hstvumCJrrbS ⑼ 
avc jr»o lonjcv* 3bs*tv* 


uscs 

thcsc iyp cs . 



If you were accessing a guitar, and wanted to know who 
built it, here’s how you could do that: 



We (W 七 Kavc ms*bruw^ 七 - 

spcd.i-P'»d. subclasses y \ o ^, so 七 he 
jui-tav is vc^vcscwtcd by a>r\ 
ms-tay\tc oi Ins-tvumcjrvt 



spec 


> Instruments 


X 


pec 



The /hst<rumch-t has av\ 

^odiaied with it {o s ^ c 
'^t<rumch-t p<ropcv-ti C s. 



properties 



°Perfy va^ 

Instrument properties / 


/W 愐 払 ? W as a 

Ma? d _/vaW 

J 


getProperty("builder") 


instrument. getSpec () • getProperty (''builder"); 
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good design = flexible software 


Code Magnets 


Using a Map for storing properties seems like a good idea, but let’s see how things 
look once we actually code up a new version of InstrumentSpec. Your job is to 
finish off the code below using the magnets at the bottom of the page. 


import java.util. 
import j ava.util. 
import j ava.util. 


public class InstrumentSpec 


private 


properties 


public 工 nstrumentSpec( 
if (properties == 
this.properties = 

} else { 

this.properties = 

} 

} 


new 


new 


0 


public 


getProperty(String 


return properties.get 


public 


getProperties() 


return 


public boolean matches(_ 

for (_ i = otherSpec. 


();){ 


String _ 

if ( !properties.get 


otherSpec.getProperty( 
return ; 


otherSpec) { 
_() .keySet (). 


0 ； 


(String)i. 


_0 ； 

).equals( 

))) 


return 
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the new InstrumentSpec class 


Code Magnets Solutions 



Using a Map for storing properties seems like a good idea, but let’s 
see how things look once we actually code up a new version of 
InstrumentSpec. Your job was to finish off the code below: 


import java.util 
import j ava.util 
import j ava.util. 


Ilteratorj 

jn^ashM^^H 


public class InstrumentSpec 



properties; 


private 


public InstrumentSpec 
if (properties == 
this.properties 
} else { 

this.properties = new 

} 

} 


HashMapH 


Vou 6ould adualW ^ 


IHashMap I 


)； 

- 




public 
retur 

} 

public 
retudn 


n properties.get 


Art.v LSt.H ncr IP r 

opertyName ) 

IpropertyName H 




Mar) 








ties () 


public (Jlnstrumen^^ 


for 


Iterator 


)ec 


otherSpec .(getProperties 


hasNext 

String ■ r , ro perty'Name 
if ( !prlperLies.yet( 


郎 - 

i) 

){ 

.keySet(). 

iterator 






0 ； 


other, 
return 


false 


■Prfperty IpropertyName 


return 



Be suv-c you goi ilicsc two vigKt ； 
oilicvy/isc, matdlicsO y/ill always 
\rciuVh tile y/voi^g vesuli. 


|gp.tProperti^s 

: alse 


null 


InstrumentSpec 
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e no . 

Questions 




So now both Instrument and 
InstrumentSpec are concrete classes? 


Right. Instrument isn't just 
a concept anymore; it represents actual 
instruments in Rick’s inventory. And 
InstrumentSpec is what clients use to 
pass in their specs when they’re searching, 
and what instrument uses to store 
properties for an instrument. 




So I can get rid of my Guitar and 


Mandolin subclasses? 


Yup. As well as Banjo, Dobro, 
and any other instrument-specific subclasses 
of instrument you may have created. 




And that’s because we use the 


Instrument class directly now, right? 


A! You got it! Remember, you typically 
subclass because behavior changes. In the 
instrument subclasses, no behavior 
was changing; in fact, all we did for each 
instrument subclass was create a new 
constructor. That added a ton of classes, 
reduced the flexibility of our app, and really 
didn’t give us any helpful functionality. 


I understood getting rid of 
Guitar and Mandolin, but I’m confused 
about why we don’t need the different 
subclasses of InstrumentSpec anymore. 


I never would have figured out 
that we didn’t need subclasses for 
instruments or their specs. How am I 
suDoosed to ever aet aood at this? 


It’s OK; that’s one of the trickiest 
parts of the design of Rick’s application. 
Remember, one of the key principles in any 
00 design is to encapsulate what varies. In 
Rick’s app, the properties of each instrument 
varied. So we pulled those properties out of 
InstrumentSpec, and put them into a 
Map. Now, when you add another instrument 
with a new property, you can just add the 
new property as a name/value pair in the 
properties Map. 

And with less classes to deal with, 
our software is more flexible? 

In this case, that’s true. There 
are certainly times where adding 
classes will make your design more 
flexible, though. Remember, adding an 
InstrumentSpec class helped separate 
instruments from their properties, and that 
was good; but in this chapter, we’ve been 
removing classes, and that’s made it easier 
to add new instruments to Rick’s software. 


A! The best way to get good at 
software design is to write software! In 
Rick’s application, we had to go down some 
wrong paths—like adding Guitar and 
Mandolin classes—to figure out what the 
right thing to do was. 

Most good designs come about through bad 
designs; almost nobody gets it all right the 
first time. So just do what makes sense, 
and then start applying your 00 principles 
and patterns to see if you can make 
improvements to what you’ve got. 


Most g ooJ 
designs come 
from analysis ol 
baJ desicfns. 

» ■ ■ o _ ■ 


Never te 

alraict to make 
mistakes anct 
tken ckange 
tilings arouncL 
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updating rick’s application 


Finishing up Rick's app: the 
IwstrumcwtTypc enum 

We’ve almost got ourselves a great piece of software. Let’s 
follow through on our new design ideas, starting with a 
new enumerated type for each instrument type: 


So -these a\rc -the -types o( 
ihstirumch-ts -that Ridk sells. 



public enum InstrumentType { 

GUITAR, BANJO, DOBRO, FIDDLE, BASS, MANDOLIN; 

public String toString() { 

switch(this) { 


case 

GUITAR: 

return 

' 、 Guitar 〃； 

case 

BANJO: 

return 

''Banjo ”； 

case 

DOBRO : 

return 

''Dobro"; 

case 

FIDDLE : 

return 

' 、 Fiddle 〃； 

case 

BASS: 

return 

''Bass"; 

case 

MANDOLIN: 

return 

''Mandolin” ； 

default : 

return 

''Unspecified 


0 String(): String 

I 


InstrumeH'ype.j 


lava 



-toS-t^rihjO jusi 
r»»akcs i*t casicv -to 
ou*t. 


Let's update Iwvcwtory, too 

With the changes to Instrument and InstrumentSpec, 
our Inventory class starts to get much simpler: 


public class Inventory 


Inventory 

inventory: Instrument [*] 

addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 
search(lnstrumentSpec): Instrument [*] 


public void addlnstrument(String serialNumber, double price , 

InstrumentSpec spec) { 

nis Li umenL inctrument 一 nuli-; 

( spee~(^n i t ^ r.Sppn) { 

i n rnm^nf- = npw nni / oqt-h =al Mnml^or' ; / Cm i-h ^ c ： por-.qppr. ^ : 




pi .qp if (i n Q-h^nr-on-F i riTp^^- 

instrument — new Mandolin (ocrialNumbcr ^ — f ri ^ (Maninl i nSppr.') 


Instrument instrument = new Instrument (serialNumber, price , spec); 

‘inventory .add (instrument); 


// etc 


Now wcVc able {o ihsia^tiatc 

IhstirumCh-t dilrcd-tly, sihde it's 

竹。 lohjc\r abs-t^adi. __ _ 
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Inventory.java 

































good design = flexible software 


parpen your pencil Let ， s see what we ， ve done . - 

We’ve made a ton of changes to Rick’s software, all in the name of “more flexibility.” 
Let’s see how things look now. Flip back to the class diagram of Rick’s app on page 
234, and recall what things looked like when we started. Then, below, draw a class 
diagram for how Rick’s application looks now. 


Answers on the next pa^e! 
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more flexibility 

Pehold: Rick's flexible application 

We’ve made a ton of changes to Rick’s application... and it’s easy to 
forget what we’ve been working towards. Look at the class diagram below, 
though, and see how much simpler Rick’s application is now: 


\s^i abstv-att 






usihj a /Wap 
■to stoirc dll -the 
piropcirtics, so 
wc doir» ； -fe heed 

subclasses (oy c3dh 
i^siv-umch-fe -feype- 


Inventory 


addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 

search(lnstrumentSpec): Instrument [*] ^ - 


inventory 


I 的 veyrtovY has just OY\t scavt^O 
method y \ o ^, a 灼 d method 

vetuvirv r»»ultitles o-f 

rnattiimj mstyumcwts. 


* 


\/ 


Instrument 

serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 

M 



|r\stvvAwCr>*t »sir\ t 
abstvatt a^ovc, 
also v-'»d o-f 
all those mstnAW ⑼七 - 
subclasses. 


spec 


W C added a ^ 忧 ’ 


InstrumentSpec 

properties: Map 

getProperty(String): Object 
getProperties(): Map 
matches(lnstrumentSpec): boolean 


A" o*f "tKcsc Chu»»»c\ra-tcd -type 
used by -tKc pvopc\rtics /VJap 
in |hS't ， \ruw»Ch'tSpcd. So y/cVc V(V*y 
loosely Coupled Kc^-c/ 
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good design = flexible software 


Put does the application actually work? 

Rick’s software looks a lot better than it did way back at the beginning 
of this chapter — and it sure looks better than when we added all those 
subclasses for banjos and mandolins. But we’ve still got to make sure his 
search tool actually works! So let’s update our test class, and check out how 
searches work with the new version of Rick’s software: 



Findlnstrument.java 


public class Findlnstrument { 


public static void main(String[] args) 

// Set up Rick's inventory 
Inventory inventory = new 工 nventory() 
initializelnventory(inventory); 


^ ow Achts <Pi|| ou 七 


type Z u ^ 

JLa i h f ou d ^ hatk 3 … W 

dous ， 阶叫—心似 ‘ 4 


Map properties = new HashMap(); 
properties .put (''builder" , Builder. GIBSON); 
properties .put (''backWood", Wood.MAPLE); 

InstrumentSpec clientSpec = new InstrumentSpec(properties); 



List matchinglnstruments = inventory.search(clientSpec); 
if (!matchinglnstruments•isEmpty()) { 

System. out. print In (''You might like these instruments:"); 
for (Iterator i = matchinglnstruments•iterator(); i.hasNext() 
Instrument instrument = (Instrument)i.next(); 

InstrumentSpec spec = instrument.getSpec(); 

System. out. print In (''We have a 〃 + spec . get Property (''instrumentType^) 
'' with the following properties :’’）； 
for (Iterator j = spec.getProperties().keyset().iterator(); 
j.hasNext(); ) { 

String propertyName = (String)j.next(); 
if (propertyName • equals (''instrumentType")) 
continue; 

System, out .pr in tin ('' 〃 + proper tyName + 

spec.getProperty(propertyName)); 

} 

System. out. print In ('' You can have this 〃 + 

spec . get Property (''instrumentType^) + '' for $’’ + 
instrument. getPrice () +、'\n - ’’）； 


sells. 

lA/c Kavc -to >wov-k a 
little mov-c div-ctily 
Map 

uses, 

bui i 七 、 tasy 灼 。… *bo 
just loop C3d.ii 

pv-o^cv-iics 
3y\d ou*t. 



^ w^h-t -to skip ovcv 

prop 吻 
al ^ d y ^dled 

that ^ s^i | oofi 


else { 

System. out .printIn (''Sorry, 


we have nothing for you. ,r ) 


// initializelnventory() method here 




s 
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initializing rick’s inventory 


Inventory Roundup_ 

To see if the new version of Rick's software works, we need to run a search on 
more than just guitars. Your job is to write code for the initializelnventoryO 
method in Findlnstrument.java, and add several guitars, mandolins, and 
banjos to Rick's inventory. Below, we've listed the instruments Rick currently 
has, and even written code to add the first guitar to help you get started. 



Guitars 


Collings CJ 6-string acoustic, 

Indian Rosewood back and sides, Spruce 
top, Serial #11277, for $3999.95 


Mandolins 


Martin D-18 6-string acoustic. 

Mahogany back and sides, Adirondack top. 
Serial #122784, for $5495.95 


Gibson F5-G acoustic mandolin, 
Maple back, sides, and top, 
Serial #9019920, for $5495.99 





Fender stratocastor 6-string electric, 


Alder back and sides and top, 
Serial #V95693, for $1499.95 


Fender stratocastor 6-string electric, 
Alder back and sides and top, 

$1549.95 


atbrA ) 士 does 灼七 
*to w\3y»diolms. 




Gibson SG'61 Reissue 6-string electric, 
Mahogany back, sides, and top, 

Serial #82765501, for 


for $1880.^ 
Gibson 
■ Maple 


>dv^os doTm 
a -foP y/ood. 


Banjos 



y/V)CV*C 心 "七 

^uitav- abcwc 

\s added *to s 
mVcr\*tov-7- 


;on Les Paul 6-string electric, 
back, sides, and top, 

Serial #70108276, for $2295.95 


Gibson RB-3 5-string acoustic banjo, 
Maple back and sides. 

Serial #8900231, for $2945.95 


Banjos do V^avc 
a >/ood. 


private static void initializelnventory (工 nventory inventory) 
Map properties = new HashMap(); 

properties•put(''instrumentType” ， 工 nstrumentType•GUITAR); 
properties . put (''builder”，Builder . COLLINGS); 
properties .put (''model’’ ，、 'CJ ’’）； 
properties .put (''type’’，Type .ACOUSTIC); 
properties .put (''numStrings’’ ， 6); 

properties . put (''topWood” ， Wood. INDIAN—ROSEWOOD); 
properties • put (''backWood", Wood. SITKA); 
inventory. addlnstrument (''11277 〃， 3999.95, 
new 工 nstrumentSpec(properties)); 

// your code goes here 


wiriic todc 

卞铋 add tn 
shoWh afcovc 


Findlr 
stru- 
ment 
main()} 


Findlnstrument.java 
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good design = flexible software 


Test driving Rick's 
well - designed software 

Be sure you’ve added all the instruments shown on 
the last page to your initializeInventory () 
method in Findlnstrument. java, and then 
compile all your classes. Now you’re ready to take 
Rick’s software for a test drive... 


...well, almost. First, you need to figure out 
what a search based on the current version of 
Findlnstrument should return. Here’s the set of 
preferences that Rick’s current client has supplied: 


Ride’s 


did^i 






Map properties = new HashMap(); 
properties . put (''builder”，Builder . GIBSON); 
properties • put (''backWood” ， Wood.MAPLE); 
InstrumentSpec clientSpec = 

new 工 nstrumentSpec(properties); 




Based on those specs, look over the instruments 
shown on the last page, and write in which guitars, 
mandolins, and banjos you think Rick’s search tool 
should return: 


Findlnstrument.java 
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adding to rick’s inventory 


Inventory Roundup Solutions 

To see if the new version of Rick’s software works, we need to run a search on 
more than just guitars. Your job was to write code for the initializelnventoryO 
method in Findlnstrument.java, and add several guitars, mandolins, and 
banjos to Rick’s inventory. 


TW»s »s a 
bit J a 

y/cVc 

just 

ovcv 

dv\d ovcv*. 
L 


private static void initializelnventory ( 工 nventory inventory) 
Map properties = new HashMap(); 

properties • put (''instrumentType” ， 工 nstrumentType • GUITAR); 
properties . put (''builder^ 


.Builder.COLLIN 

properties .put (''model ’’， 
properties . put (''type’’，Type .ACOUSTIC); 
properties • put (''numStrings’’ ， 6); 
properties . put (''topWood” ， Wood. INDIAN—RO 
properties • put (''backWood", Wood• SITKA); 
inventory. addinstrument (''11277 〃， 3999.95, 
new 工 nstrumentSpec(properties)); 


Collings CJ 6-string acoustic, 

Indian Rosewood back and sides. Spruce 
top. Serial #11277, for $3999.95 

SEWOOD); 



properties . put (''builder”，Builder . MARTIN) 
properties • put (''model", 、 'D-18 ’’）； 
properties • put (''topWood” ， Wood.MAHOGANY); 
properties • put (''backWood”，Wood • ADIRONDACK); 
inventory. addlnstrument (''122784 〃， 5495.95, 
new 工 nstrumentSpec(properties)); 

properties • put (''builder”，Builder . FENDER); 
properties .put (''model” ， ''Stratocastor ”）； 
properties . put (''type”，Type . ELECTRIC); 
properties • put (''topWood” ， Wood. ALDER); 
properties • put (''backWood” ， Wood. ALDER); 
inventory. addlnstrument (''V95693” ， 1499.95, 
new 工 nstrumentSpec(properties)); 
inventory. addlnstrument (''V9512” ， 1549.95, 
new 工 nstrumentSpec(properties)); 


Martin D-18 6-string acoustic, 

Mahogany back and sides, Adirondack top. 
Serial #122784, for $5495.95 


Fender stratocastor 6-string electric, 
Alder back and sides and top, 


Serial 




Fender stratocastor 6-string electric, 
Alder back and sides and top, ’ 
Serial #V9512, for $ 1549.95 


TV>C \o>r t>wo 
a\rc i\\t same ； o^ly poprbes m 
卜 s 七 vu 眯忧七 ave 
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good design = flexible software 


Poy \’ 七 
-fovjct bo 

S*bri 呼 
-fov 七 
md^doln^ 



vcus'm^ 

七 he same 

^vo\>cvtics 

map. 



properties . put (''builder”，Builder . GIBSON); 
properties • put (''model”，、'Les Paul ’’）； 
properties • put (''topWood” ， Wood.MAPLE); 
properties • put (''backWood” ， Wood.MAPLE); 
inventory. addinstrument (''7010827 6〃，22 95.9 
new 工 nstrumentSpec(properties)); 


Gibson Les Paul 6-string electric. 
Maple back, sides, and top. 

Serial #70108276, for $2295.95 


properties • put (''model”，、'SG '61 Reissue ”）； 
properties • put (''topWood” ， Wood.MAHOGANY); 
properties .put (''backWood ^, Wood.MAHOGANY); 
inventory. addin strument (''827 65501 〃， 1890.95, 
new 工 nstrumentSpec(properties)); 


Gibson SG '61 Reissue 6-string electric 
Mahogany back, sides, and top, 

Serial #82765501, for $1890.95 


Gibson F5-G acoustic mandolin, 
Maple back, sides, and top, 
Serial #9019920, for $5495.99 


properties.put(''instrumentType” ， 工 nstrumentType.MANDOLIN) 
properties .put (''type’’，Type .ACOUSTIC); 
properties • put (''model", 、 'F-5G ’’）； 
properties .put (''backWood ^, Wood.MAPLE); 
properties • put (''topWood", Wood.MAPLE); 
properties . remove (''numStrings"); 
inventory. addin strument (''9019920 〃， 5495.99, 
new 工 nstrumentSpec(properties)); 

properties . put (''instrumentType” ， 工 nstrumentType . BANJO) 
properties • put (''model” ， 、 'RB-3 Wreath ’’）； 
properties . remove (''topWood"); 
properties . put (''numStrings ”， 



doh ； -fe Kave 
a "top wood ； so wc 
ijo iremove 
"feKis pvopcirty. 


5 )； 

inventory. addin strument (''8900231 〃， 
new 工 nstrumentSpec(properties)); 

} 


2945.95 


Gibson RB-3 5-string acoustic banjo 
Maple back and sides. 

Serial #8900231, for $2945.95 



Findlnstrument.java 
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rick’s software works like it should 

Rick's got working software, 
his client has three choices: 



File Edit Window Help SatisfyTheCustomer 


% java Findlnstrument 

You might like these instruments : 

We have a Guitar with the following properties : 
topWood : Maple 

backWood : The ^ cc is B^ s 

builder : CgibsoiT) S P 故 s because H / 

type : electric ^ple b^k a,d sides 

model: Les Paul is wde b y 与 ib Soh ' d 

numStrings : 6 ' 

You can have this Guitar for $2295.95 


We have a Mandolin with the following properties : 

topWood : Maple , 八， ,i. 

backWood : C^aple) tteve s a ^ ^ o 

a md\>le batk … 七 his 

also meets s ? c6s . 


builder : QGibson 
type: acoustic 
model : F-5G 

You can have this Mandolin for $5495.99 


We have a Banjo^with the following properties : 

backWood^^^§> 仏 c mo 代 |c 

builder : CgibsorT^ 

numStrings: 5 that docs „t matter. 

You can have this Banjo for $2945.95 





e no . 

Questions 


My output isn’t the same as yours. What did I do wrong? 


A! If your version of Rick’s tool returned different guitars, or 
output the same guitars but with different properties, then you should 
be sure you have the same instruments in your inventory as we 
do. Check the exercise on page 260, and the answers on page 
261-262, and make sure the instruments you have in Rick’s inventory 
match ours. 




Is this really a good test since we only have one banjo 


and one mandolin? 


A: That’s a great question, and you’re right, it would be better 
to have a few more mandolins and banjos to really make sure Rick’s 
search tool picks only matching mandolins and banjos. Go ahead 
and add a few non-matching banjos or mandolins, and try testing out 
Rick’s search tool with the additional instruments. 
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good design = flexible software 


Thafs great that you ve got your software 
working right, but dotVt start patting yourself 
on the back for a great design just yet. Me and 
my buddies at the bureau of change are here to see 
just how cohesive your software really is. 



来 


来 


来 


How easy is it to change 
Rick's software? 

Is Rick's software really 
well - designed? 

And what the heck does 
cohesive mean? 
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the ease-of-change challenge 



Let’s add support for dobros and fiddles back into Rick’s application. We 
tried to do that earlier, back in the first part of Chapter 5, and it turned into 
a total mess. Things should be much easier this time, right? Below is the 
class diagram for the current version of Rick’s software. 
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good design = flexible software 



Let’s apply the ease-of-change test to our software: 

o How many classes did you have to add to support 
Rick’s new instrument types? 


how easy i-fe \ s {p 

y oWr so-f-twav-c is Ohc 
J the best ways "to -fijuv-c 
ou-fe i-f you \rcally Kav C wdl- 
dcs—d so^-twav-c. 


❺ How many classes did you have to change to support 
Rick’s new instrument types? 


❺ Suppose that Rick decided that he wanted to start 
keeping up with what year an instrument was made 
in. How many classes would you need to change to 
support keeping up with this new information? 


o Rick also wants to add a new property, neckWood, that 
tracks what wood is used in the neck of an instrument. 
How many classes would you need to change to 
support this property? 


► Answers on page 268 
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easy to change? 



Let’s add support for dobros and fiddles back into Rick’s application. We 
tried to do that earlier, and it turned into a total mess. Things should be 
much easier this time, right? 


Let’s apply the ease-of-change test to our software: 

o How many classes did you have to add to support 
Rick’s new instrument types? 

None! We got rid of all the ihstrument-specific 

subclasses of Instrument and iHstrumeHtSpec. 


❾ How many classes did you have to change to support 
Rick’s new instrument types? 

Om we need to add any new instrument types to the 

IhstrumeiitType enumerated type. 

❺ Suppose that Rick decided that he wanted to start 
keeping up with what year an instrument was made 
in. How many classes would you need to change to 
support keeping up with this new information? 

None! You can just store the year that an instrument 

was made in the properties Map in liistrumeiitSpec. 

o Rick also wants to add a new property, neckWood, that 
tracks what wood is used in the neck of an instrument. 
How many classes would you need to change to 
support this property? 

One ih the worst case, and maybe none! neckWood_ 

is just another property we can store m the_ 

liistrumeiitSpec map... but we might need to add new 

wood enumerated values to the Wood enum. 
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good design = flexible software 


Sweet! Our software is easy to change... 

...but what about that "cohesive" thing? 


A cohesive class does 


丁 lie move dolicsivc 



youv dlasses ilic 

Ki^Kev *tlic doliesion 
o( youv s<>f*ty/a\rc. 


one thing ^ 

really well and 


Look -^ods 

V ouv tlasscs-do all relate 

to tV^c 70UV tlass. Hr 

V ou v,avc a wC tV,od tv^at looks 

U d ? 心，•七 bcl °^ 

m av>otV^CV- tlass. 


does not try to 

—- do 

or be 


something else. 


Cohesive dlasscs av-c -fodused 
伽 s£cdi£id -tasks. 0^ 
(i^vch-toiry class wov-v-ics about 
j us "t 尺 kk’s irwcy\iory, ho-fe 
what woods dar> be used 
a OV" how "to dompav'e 

"two msiv-umcrrt speds. 


I^stv'urwc^ docsy\ *t bey 
V^d^dile scavtVics, ov kcc\> 
u? y/i*tV\ y/V\at y/oods avc 
available. It is (o^sed on 
acstvib'mj mstv-umc^-t-a^d 

^^2^3 g ' sc， 


Scfeolar^CoTiiet 


dohesioh. Cohesioh mc3suV"CS -the dtyrtt of doyme&fcivrb / 

■the clcmch*U of d sih^lc module, dlass, o\r object. The hio^e v 
七 he dohesioh of your sof*tv/a\rc is, *thc more wcl[—dc£mcd dr\d 



relate 

Y° 


rela 七 ed *tiic responsibilities of eddh ihdividudl dldss \y\ 
youv applidaiioh. dlass has a very spedi-f id sc*t 
of dosdy \ rela 七 ed 3 d*tiohS i-t pcv*-fo\rms. 
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cohesive classes are focused on one thing 


Cohesion and one reason for a 
class to change 

You may not realize it, but we’ve already talked about 
cohesion in this book. Remember this? 



Every class should attempt to 
make sure that it has only one 
reason to do this, the death of 
many a badly designed piece 
of software. 




TKis was one o-P -fehc ahswev-s 
^ 00 CATASTROPHE/ 
仏 you \rcmcmbcv- wha-t -the 

<\UCstioir> was? 


Cohesion is really just a measure of how closely related the 
functionality of the classes in an application are. If one class 
is made up of functionality that’s all related, then it has only 
one reason to change... which is what we already talked about 

in 00 CATASTROPHE! 

Here are the classes we talked about when we made sure 
each class had only a single reason to change: 


TV^c o-f catV> 

classes «S - defmed. 

is a W15W7 toV>csWc tlass, 
and makes \i cas^ 

otV^cv classes. 



Cayx y° u ^ of a 

^ tla S s 

Cohesive? 
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good design = flexible software 



e no , 

Questions 


So cohesion is just a fancy 
word for how easy it is to change my 


application? 




But all that means the software 


will be easier to change, doesn’t it? 




Wouldn’t software that’s cohesive 


be easier to reuse, as well as change? 


A 丨 Not exactly. Cohesion focuses on 
how you’ve constructed each individual 
class, object, and package of your software. 
If each class does just a few things that are 


A! Most of the time, yes. But remember 
the version of Rick’s application that 
we started with in this chapter? It only 
supported guitars, and we didn’t even have 

Instrument or Instrument Spec 


A! You got it. High cohesion and 
loose coupling adds up to software that 
can easily be extended, or even broken up 
and reused, because all the objects in the 
software aren’t interdependent. 


all grouped together, then it’s probably a 
highly cohesive piece of software. But if you 
have one class doing all sorts of things that 
aren’t that closely related, you’ve probably 

got low cohesion. 

So highly cohesive software is 
loosely coupled, right? 

Exactly! In almost every situation, 
the more cohesive your software is, the 
looser the coupling between classes. 

In Rick’s application, the inventory 
class really worries just about managing 
inventory—and not about how instruments 
are compared or what properties are stored 
in an instrument spec. That means that 
inventory is a highly cohesive class. 

That also means it’s loosely coupled with 
the rest of the application—changes to 
instrument, for example, don’t have a 
lot of effect on the inventory class. 


classes. That was pretty cohesive software— 
Guitar was very loosely coupled with 
inventory. However, it took a lot of work 
and redesign to support mandolins. 

When you fundamentally change what an 
application does—like going from selling only 
one type of instrument to multiple types—you 
may have to make lots of changes to a 
design that’s already cohesive and loosely 
coupled. So cohesion isn’t always a test 
of how easy it is to change software; but 
in cases where you're not dramatically 
changing how software works, highly 
cohesive software is usually easy to change. 


Think about it this way: the higher the 
cohesion in your application, the better 
defined each object’s job is. And the better 
defined an object (and its job) is, the easier 
it is to pull that object out of one context, 
and have the object do the same job in 
another context. The object is happy to 
just keep on doing its very specific job, no 
matter where it’s being used. 

And we’ve been making Rick’s 
application more cohesive throughout his 
chapter, haven’t we? 




And high cohesion is better than 


low cohesion? 


A! For the most part, yes. But let’s look 
a little bit closer at that question... 


A: Right. Good 00 design is when 
each class and module in your software 
does one basic thing, and that one thing 
really well. As soon as one class starts 
doing two or three different things, you’re 
probably moving away from cohesion, and 
good 00 design. 
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nc^rc^s wKc\rc 
3 uiia\rs. TKc 
cvch -fcKoujK 
ircdcsijh -to c 



Rcmc^bcv tv^is simple tlass 
dl aa^ W ^7 badk m 

I? Wc j us “ ad 亡。 

Masses, ^ Lot 

v/cli-dcsi^cd OV vc ^7 ^cs«vc- 


Ri^k was jusi sellihj 

a PP >was vcally doKesive, 

>we lidd 心 do some v-c^l 
>dd suppoirt -fo\r ^a^dolihs. 



Heve >was ouv -f ivst a 七七〜七 
{p add su^ov-t -fov multiple 

•ms 七 vumcrv 七七 W. U ⑽ 
dc-fm'itcly ^avc lo>wcv 6oV>csioir» 
Kev-e tKaw m tKc previous vcvsioyv. 



addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 
search(GuitarSpec): Guitar [*] 
search(MandolinSpec): Mandolin [*] 




Instrument 

L 

1 serialNumber: String 

1 price: double 

I getSerialNumber(): String 

1 getPrice(): double 

1 setPrice(float) 

1 getSpec(): InstrumentSpec 



> 



getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 


\ style 

I Style I 

[toStringQ: String 


increasing cohesion 


Rick’s software, iw review 

So have our changes to Rick’s software resulted in high 
cohesion? Are our objects loosely coupled? And can we 
make changes easily? Let’s take a look: 



TV ^ca J 

oU 咖 咖 wc 

dcs.，. 


uosaAS % 
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good design = flexible software 


Ut^^r . suvc r ^t 

soR 祕七 ” a 以 


rtcvcs ^ctWm^sarc 
6o ^o„ loose 6ou ? M> ^ 

: 伽 , 祕身 a 吵 

ei <.W a«d 一 . 




This was j v-cal low po'm-fe 
• m OWr dts\^... -tv-ymg -to 
^dd a hew ihstv-urr»cr>-t 
■type w5s s disas£cv*. 


Inventory 


addlnstrument(String, double, InstrumentSpec) 
get(String): Instrument 
search(lnstrumentSpec): Instrument [*] 


inventory 

\ 

•k 


Instr 

ument 


serialNumber: String 
price: double 

getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpecQ: InstrumentSpec 




^soec 

1 

Inst 

rumentSpec 

properties: Map 

getProperty(String): Object 
getProperties(): Map 
matches(lnstrumentSpec): boolean 





THIS is your goal … 
so^*twavc 七 hat’s 

move dohesive *thvou5hou*t 

the design life dydlc. 



ilie design life cycle 
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great software is good enough 


O 


This sounds great and all, but how 
do you know when you re done? I mean, 
is there some sort of scale of cohesion, 
and when I get to a 、、 10 〃 or* whatever, it 
means that I'm finished? 



Great software is usually 
about being good enough. 

It’s hard to know when to stop designing 
software. Sure, you can make sure that your 
software does what it’s supposed to do, and 
then start working on increasing the flexibility 
and cohesion of your code. But then what? 

Sometimes you just have to stop designing 
because you run out of time... or money... 
and sometimes you just have to recognize 
youve done a good enough job to move on. 

If your software works, the customer is happy, 
and you’ve done your best to make sure 
things are designed well, then it just might be 
time to move on to the next project. Spending 
hours trying to write “perfect software” is a 
waste of time; spending lots of time writing 
great software and then moving on, is sure to 
win you more work, big promotions, and 
loads of cash and accolades. 
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Knowing whew to say "It’s good enough! 


jj 


I love it! I can finally sell any 
kind of instrument I want, 
and help my clients find just what 
they're looking for. 


O 



Make sure the 
customer is happy 


Bc-Pov-c y ou cvcv " a 
^V*ojc6*tj you sl>w3Y s *to 
make suv-c youv so^t>wavc 
4a 七 it's suffosed to do. 


does 


Really nice design here. High cohesion, the 
classes are loosely coupled... I'll bet the next 
time Rick needs something changed, we woiVt have 
too much trouble at all. 


Ouc you VC o^oi ^Uhdtio^lity 
do^ r，ove o, -to Mki% 3ood 
dcs ’ d^isio Mj usihj solid 00 
?^\ ? ks -to add ^Icxibili-ty. 


Make sure your 
design is flexible 


If youVe done both of these things, it may 
just be time to move ow... to the next project 
the next application, even the next chapter! 
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ooa&d toolbox 



Tools for your 00A 备 P Toolbox 

Wow, you’ve really come a long way since we 
started working with Rick way back in Chapter 1. 
You’ve learned a ton about design, so let’s do a quick 
review of what you’ve added to your toolbox. 


^ood c ⑽ u\rc 

Y/o\rb like youv 己 ust>m 伏 s c: 

Make suv-c Y ouV， v-c«\u*»\rcmc^ 
\)\j dcvclo^m^ uSC eases 

Use you\r use ^ascs -to 
七 Wmy youv* d.us*tomCV-s -fov-^ 


—wtu 3 w “ ka ^ 


oi 


Youv- use ^ascs Will al 

ov missm^ \rC < \utV-CwC^'U 

Kavc- 

YouV V-C^UlV-CwCl^'ts Wtll 
yov/) OVCV* 


^alysis a 灼 di Pesi^ 

_-de 呼 ed s<^ W is easy —e 
ad wted. 

Use \>^t 00 ^m6 ? lcs l*.kc c^aHatiov, 

—e make vou^r 

nxort -flcWiWc- 

1^ a dcsi^ is^t <(WiWe, 七 b CH^N^ 
IT/ Kcvcv settle oy^ bad dcs*»^, cvev^ \\ 
•Js ^our bad dk 吻 tV^Uas to 〜乎 

Make su\rc ca^ <>^ youv classes is 
to\\ts\Mc cadh Jc youv classes should 

-Po^us oy. do\^ out T_$ 代 alb/ J 

sV.vc -fov W.^hcv dohcsioL as you 
mo vc -th\rou^ youv software's dcsi^ 

life 匕 


00 Prihdiples 


Encapsulate v/ha 七 vavics. 

Code *to at\ m-tev-fade rai\\tr Aa 的 *to an 

EaA dlass \y\ youv appli^a*tioirv should have o^ly 
ov\t reason *to Aa 呼 . 

Classes av-c about bcliaviov airvd -fuirvd-tio^aliiy- 


The joal yod 
dcs'15^ is Ki^ly 
6oV\cs'»vc, loosely 
6ou\>led so-f*t>wav-c. 


BeWer, 00 CATASTROPHE! 
ad tV>is tKaptev-, we’ve added 
<YAi*tc 3 -fc>N >r»C>N 00 ^v*mt»^lcs *to 
ouv* *toolbo%. 
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good design = flexible software 




OOA&D Cross 

This one is a particularly tough puzzle ： almost all the 
answers are more than one word, and they’re spread 
across both parts of Chapter 5. Good luck, and keep 
that left brain working. 



3, N«nvr lcjJ& \d this rf you help il r 
fl. Srcot iof frwar* is caly ixs _ 

12. 寸 wore thva 十 i wUy to cKangc •Idl 

13, thi£ +* what vanae. 

IB. Waver ba ra;d t& do this t& ymjr de 玄 igr«. 

17. Thif wiir kJII good 

13. are dbciuf ^h\£. 

iy Whpn rtnp. th.m.g« mfirip： up af annthftr 


L Alwuysi LEKi£ to Ihi^ pf |jdS^ ibfe. 

2, Mu^t come from anafyj^ of 

thtic. 

4. Abstract arc written this way m 

UML c\as^ 

5.. When a c\<m inharits beKavicr from another 
dossi. 

i>. This wa^ the typ^ flf group ensuring your 
^fuftuifirp ： wn< Ki^hJy f^hp^rvp. 

7. Apply these to odd tlexibilF+y to your 
Software. 

9. Cohesive cla^je^ do this really wdL 

10 . Dfln't be afraid to do th^s■ Ft wfM help yau 
find betlcf ^uFul<uri^. 

11. We uStsd Ihi^ Ituil lu if RiLk'^ 
application mgs cq-Kc^ ivc, 

H, Hitghry cohfidivifi : So ft ware b a\sa almost 
always _ coupled ， 

16 .. Great iof tware muslt always da- what it \& 

_ ___ 骨。 do. 
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did you get the same answers as we did? 
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solving really big Pro 


ems 


“My Name is Art Vandelay,., 


I am an Architect^ 



I was just thinking... do you 
remember if we ever tightened 
the bolts down on those basement 
girders? Oh well... . 


-—— 
"vr- 


It’s time to build something REALLY BIG. Are you ready? 


You’ve got a ton of tools in your OOA&D toolbox, but how do you use those tools 
when you have to build something really big? Well, you may not realize it, but 
you’ve got everything you need to handle big problems. We’ll learn about some 
new tools, like domain analysis and use case diagrams, but even these new tools 
are based on things you already know about — like listening to the customer and 


understanding what you’re going to build before you start writing code. Get ready... 
it’s time to start playing the architect. 


this is a new chapter 
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what about big applications? 


280 


O 


Look, all this stuff about writing great 
software sounds terrific, but real applications 
have a lot more than five or ten classes. How 
am I supposed to turn big applications into 

great software? 





You solve b|g problems 
the same way you solve 
small p roblems . 

We’ve been working with fairly simple 
applications so far... Rick’s guitar shop 
had less than fifteen classes in its worst 
state, and Doug’s dog door never had 
more than five. But everything you’ve 
learned so far applies to working with 
big applications, too. 


1 Make sure your 
software does wkat tke 
customer wants it to cto. 


They atTp P tr ith9 

，心一… s wh 

〜心一 4 二減 3 

3 




Apply basic 
00 principles to 
actct flexibility 



Chapter 6 


3. Strive for a 
maintainable ， 
reusable ctesigfn. 







solving really big problems 


If s all m how you look at 
the big problem 

Think about how you work on big problems, in big 
software applications. You usually look at the big 
picture, but then start working on just one part of 
the application’s functionality. 

The best way to look at a 

big problem is to see it as lots of 

individual pieces of functionality. 

You can treat each of those pieces as 
an individual problem to solve，and 
apply the things you already know. 

Once you get one part of an application working 
like you want it to, then you can move on to another 
piece of functionality within the app. At each step, 
though, you’re applying the same basic principles 
we’ve been talking about for the last 250 pages or so. 


tw»s m ?Mi^ 

\S v-call7 a 

e.ollc^t»ov> ok 
“WaVrbes ， 

catV> ok 

a smalls ov> 



You can solve a 
protlein Ly 
breaking it into 
lots ol functional 
pieces, and tlien 
working on eacli 
of tiiose pieces 
individually. 


Big 

Problem 
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solving big problems 


The things you already know... 

You’ve already learned a lot of things that will help you 
solve big software problems... you just may not have 
realized it. Let’s take a quick look at some of the things 
we already know about how to write great (big) software: 



By encapsulating wkat 
varies ，you make your 
application more : flexible 


and easier to dkange. 


wi(, ^ you 

一 AS: 广 球 : r 


Coding to an 
interface, ratker 


tkan to 


an 


implementation ， 
makes your 
software 

to extenett 


easier 



TWlS IS cvc^ move I 个 山 灼七 

m apps. By -to 

孙 70 U rtdut 

kcWc^ 
parts of 70 UV 
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touplC »s alv/ay s a 3 00< ^ 
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solving really big problems 


Analysis kelps 


TViis sure docs^-t v /必 
? roblems. k 
Co^s\o^ ^ your a\>p, 
mdc\>c^dcn*t catVi ^\ttt ok +u^t«o^l«ty 
•,s, ar^d h\t easier *rt is -to v/ork tv^osc 

pieces oir\C a*t 3 tw'C- 


Great software 
is easy to 
ckange anct 
extenct，anct 



you ensure 



Analysis is cvcr\ 

move 

y/rbh 

so^"t>/dv"c … and h 
most casts, you 
stavt by a^alyz-m^ 
mdwidudl fictcs 
<Jc -fur\dt»or\ali*ty, 
av\A a^alyz-mj 
i\\t m 七 eM 七 ion Jc 
•bi^osc pieces. 


your system 
works in a 
real-woriJ 
context. 


ctoes wkat tke 



customer wants 
it to cto. 


So let's solve a problem! 

Enough about what you already know; let’s see how 
we can apply these things to a brand new, really 
big piece of software. Turn the page to learn a bit 
about Gary, his new game company, and a large 
software project. 


Got a big problem? Take a few 
of these little principles, and call 
me in the morning. I bet you’ll 
have things under control in 
no time. 户 
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introducing gary ! s games 


Hcv-c s i\\t b*»3 problem weVe 
^o'm^ bo be wovk.” on fov* 如 
^ ⑽ Ws. 



Gary’s Games 

Vision Statement 


m 


Harrs Gfmes provides tramewoiKb uiat 

creale turn-based strategy games. Unlike arcade-style shoot- em-up 
games and games that rely on audio and video features to engage 
player, our games will focus on the technical details of strategy an 
tactics Our framework provides the bookkeeping detai s to e 
^nga particular game easy, while removing the burden of codmg 

repetitive tasks from the game design. 

The game system framework (GSF) will provide the core of all of 
Gary s Games. It will be delivered as a library of classes with a well- 
defined API that should be usable by all board game development 
project teams within the company. The framework will provide standard 

capabilities for: 

♦ Defining and representing a board configuration 

♦ Defining troops and configuring armies or other fighting units 

♦ Moving units on the board 

♦ Determining legal moves 

♦ Conducting battles 

♦ Providing unit information 

The GSF will simplify the task of developing a turn-based strategic 
board game so that the users of the GSF can devote the. Ume to 
implementing the actual games. 
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solving really big problems 


I'm not interested in one 
of those fancy, flashy Star Wars 
rip-off games... I want something with 
strategy, that makes you think! A 
cool turn-based war game, that’s the 

ticket. 


O 






arpen your pencil 



What should we do first? 

Below are several things that you might start out doing to get going on Gary’s 
Games. Check the boxes next to the things you think we should start with. 



alk to Gary. 



Talk to people who might 
_use the framework. 



Gather requirements. 


rite use cases. 




Start a class diagram. 


Start a package diagram 
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what should you do first? 


Hey, this is an easy one. 

We start out by writing out the 
requirements and use cases, like we did 
with Dougs Dog Doors. 


0 



Requirements and use cases 
are a good place to start- 

starting out working on a system by 
building a requirements list and writing 
use cases is a great idea. You can figure out 
what a system is supposed to do, and just 
go down your list adding functionality bit 
by bit... solving lots of small problems to 
solve one really big problem. 


But Tm not sure we really 
have enough information to figure out 
the requirements or use cases yet... all 
weve got is that fancy vision statement. 
But that really doesn't tell us much about 
what the system were building is 
supposed to do. 


\jo\Ar tcdw. 


■■■but what do we really know 
about the system so far? 

That vision statement seemed to have a 
lot of information about what Gary wants, 
but it leaves a lot open to interpretation. 


What kind of board did Gary have in 
mind? And who’s the customer, really? 
Game players or game designers? And 
will all the games be historically based, or 
do we have to support things like lasers 



and spaceships? It sounds like there’s a lot 
more we need to know before we can write 
a very good set of requirements. 
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Wc need a |ot more iwformatiow 

All we’ve got to go on with Gary’s system so far is a vision 
statement... and that didn’t tell us very much at all. So 
now we’ve got to figure out what the system is supposed 
to do. So how do we do that? 


TWs \S tailed t 一巧 … 

Uat tWmy avc 


What is the system like? 

One way you can find out more 
about a system is to figure out 


what the system is like. In other 


words, are there some things that 
you do know about that the system 


functions or behaves like? 





This is called vaHabi 
things av-c 


•iability... 




What is the system wot like? 

Another great way to find out what 
a system should do is to figure out 
what it’s not like. This helps you 
determine what you don’ t need to 
worry about in your system. 


So let’s listen m on one of ftary's 
meetings, and see what wc can find out. 
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listening to the customer 


Customer Conversation 

We need to listen in a little more on what Gary and his 
team are planning before we can get started on the game 
system framework he wants us to build. 



Remember that old computer game, 
Zork? Everybody loved that thing, 
even though it was pure text. 




c 

Bob m 




Susah ahd 7om 




h sales. 



Flc^b'il*il*ty is 
*to be key 
wcVc 5 。 叫 
•fco support 


all -these 

variations. 



Tom: Yeah, Gary loves text-based games. And people are getting a little tired of 
all the fancy graphics in games like Star Wars episode 206 (or whatever the heck 
they’re up to these days). __ 

Bethany: And we need all sorts of different time periods. We could have a Civil 
War version, with battles at Antietam and Vicksburg, and a World War I version 
over in Europe... players will love all the historical stuff, I’ll bet. 

Susan: Nice idea, Beth! I’ll bet we can let game designers create add-on packs, too, 
so you could buy a World War II: Allies game, and then buy an add-on for other 
forces that the core game didn’t include. 


tteves some 

，s y \ o {, a 

ya?W ， 6 - vA 5 awC， 


Bob: That’s a cool marketing point, too... if our system supports different time 
periods, unit types, uniforms, and offensives, we’re going to be able to sell this to 
almost anyone developing games. 


Bethany: Do you think we need to worry about battles that aren’t historical? I 
mean, we could sell our system to the folks that make the fancy starship games, and 
let them create sci-fi battles, right? 
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Tom: Hmmm." I’ll bet Gary would go for that, if they’re still creating turn-based 
games. Why not clean up on that market as well as the history buffs? 


Bob: Do you think we could market this as a system to create everything from 
online Risk to a modern-day Stratego? Those were both killer strategy board 


七 丫 … 

so v/cVc V-Ccilly 
aWmg a 七 *tuvy>- 
based >wav-^amcs. 


games back in the day... I’d love to sell our system to people that make those sorts 
of games. 


Bethany: So let’s talk details. We know we’ve got to sell this to lots of game 
designers, so we need it to be really flexible. I’m thinking we start with a nice 
square board, and fill it up with square tiles. 


Tom: We can let the game designers pick how many tiles on the board, right? 

They can choose a height and width, or something like that? - 


Bethany: Yeah. And then we should support all different types of terrains: 
mountains, rivers, plains, grass... 



〆 


Susan: ...maybe space or craters or asteroid or something for the space games... 


Bob: Even underwater tiles, like seaweed or silt or something, right? 


0^, ^ OY, 

aWt a^a\ 
s*. 


Bethany: Those are great ideas! So we just need a basic tile that can be 
customized and extended, and a board that we can fill with all the different tiles. 



djaih... 

some 

亡 orhr^ohdli 士 y 

f h thai typ c 
-to pay 

{jQ. 


Susan: Do we have to worry about all those movement rules and things that 
these games usually have? 

Tom: I think we have to, don’t we? Don’t most of these 

strategy games have all sorts of complicated rules, like a 

unit can only move so many tiles because he’s carrying 

too much weight, or whatever? 

6 ? O 


So did you get all that? YouVe 
ready to start working on my new 
game system now, right? 


Bethany: I think most of the rules depend on the 0 

specific game, though. I think we should leave 

that up to the game designers who use our 

framework. All our framework should do is 

keep track of whose turn it is to move, and ■■ 

handle basic movement stuff. 

Susan: This is great. We can build a 

framework for challenging, fun strategy 

games, and make a ton of money, too. ^ 

Bob: This is starting to sound pretty 
cool! Let’s get this to Gary and those 
software guys he's hired, so they can < 
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information, features, and requirements 


Figure out the features 

You’ve learned a lot about what Gary and his team 
want the game system framework to do, so let’s take that 
information and figure out the features of the system. 



d oUV^aw 咖. 〜 - 


s a 



Bethany: And we need all sorts of different time periods. We could have a Civil 
War version, with battles at Antietam and Vicksburg, and a World War I version 
over in Africa and Italy... players will love all the historical stuff, I’ll bet. 


寸。 "their -Pcatuirc ： di-f^V-Ch-t 
含 yp« d tevraih. This si—e 

will pvobably sev^al 

ihdividudl V*c < ^ui\rcmch'ts. 


Bethany: Yeah. And then we should support all different types of terrains: 
mountains, rivers, plains, grass... 

Susan: ...maybe space or craters or asteroid or something for the space games... 
Bob: Even underwater tiles, like seaweed or silt or something, right? 


Put what is a 
feature, awyway? 


A feature is just a high-level description of something a 
system needs to do. You usually get features from talking 
to your customers (or listening in on their conversations, 
like we just did on the last few pages). 

A lot of times, you can take one feature, and come up 
with several different requirements that you can use to 
satisfy that feature. So figuring out a system’s features is a 
great way to start to get a handle on your requirements. 



S-birtihg With the -Pcatuv-cs 
^ a system _s \rcally hdp-Pul ih 

jcdts-likc s 
•whch you do〆 七 have -to^s 
3hd just heed -to get 
a handle oh whc\rc to stav-t ， 


ot a systci 
big pv-ojed 
sys*tcrh—y/h 
details, 
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Feature (from customer) Requirement (for developer) 


Supports different 
(types of terrain. 

rteve’s a sm^lc (caWe 
七 ^\rom tusWc'r- 



A tile is associated with 
a terrain type. 




^ame designers can create 
custom terrain types. 


u- — 丁 ha 七 

-Pcatuv-C Ircsults 
… Multiple 

^C^uiv-CmChts. 

Each terrain has characteristics ^J) 
that affect movement of units. 


Get features from tke customer，and 
tken figure out tke reejuirements you 
need to implement tkose : features. 


harpen your pencil - 

、 We need a list of features for Gary’s game system. 

You’ve got plenty of information from Gary and his team, and now you know how to 
turn that information into a set of features. Your job is to fill in the blanks below with 
some of the features you think Gary’s game system framework should have. 
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feature or requirement? 



arpen your pencil 


answers 


We need a list of features for Gary’s game system. 


You’ve got plenty of information from Gary and his team, and now you know how to 
turn that information into a set of features. Your job is to fill in the blanks below with 
some of the features you think Gary’s game system framework should have. 


Supports diMeve 灼七 types -berram- 

Supports mul 七 iple *bypgs o( tvoofs o\r 

七 ha 七 ave Qjame — spedif id. 

ii 3 s 3 bo3v*di ； y>^3dlc 

>^ua\re 七 iles, eadh W\{\\ a •bevram type. 


Su^o\rbs ditfeveyrb 七 ime peviods, mdudmq 

-Pid-fcio^al pgviodls like s^i--Ci By\d (sy\{^sy. 

Supports add—modules ^oy additional 

ov battle sde^avios. 

The -Pvai^ey/ovk keeps up v/i 七 h whose 七 um 

i*t is ^oovd'ma-tcs bdsid movement 



This all seems pretty arbitrary... 
some of those features look just like 
requirements. Whafs the big difference 
between calling something a feature, and 
calling something a requirement? 


0 


li's 0^ if these 

"the exa 匕 t -Pcdtuircs you 
got, oir i-f you had move 

d 七 iled thihgs i h this 
list These avc just 
what v/e up with. 


O 



Don’t get hung up on the 
“difference” between a 
feature and a requirement. 

Lots of people use “feature” to mean different 
things, so it’s not a term you should get too 
worked up about. For some people, a feature is a 
requirement; and you’ll even hear some people 
say “feature requirement,” which really can get 
confusing. 

Others think of features as higher-level 
than requirement, which is how we’ve been 
talking about them. So it might take several 
requirements to satisfy one feature of a system. 

The main thing is that if you’re stuck on where 
to get started, especially with a big project, you 
can gather features (or requirements!) to get a 
handle on the high-level things you know you’ll 
need to take care of in the system you’re building. 
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solving really big problems 



e no . 

Questions 


乂 . So there’s no difference between a 
feature and a requirement? 

A: Well, this really depends on who 
you ask. For some people, a feature is a 
“big” thing that a system does, like “support 
different types of terrain ■” But to put that 
feature into place, there are lots of “small” 
things that the system must do, like “define 
a base terrain type” and “allow developers 
to extend the base terrain type” and “allow 
each tile to contain multiple terrain types.” 

All of these little things are considered 
requirements. So a single feature is satisfied 
by several requirements, like this: 



Requirements 

FcaWcs avc \ 

lo-b — ) 

"to 




You said, “some people.” So there 
are other ways to look at features and 
requirements? 


Right. A lot of other people don’t 
make such a distinction between a feature 
and a requirement. One feature might be 
“supports different time periods” (which is a 
pretty big thing), and another might be “allow 




So which is right? 


Both! Or neither, if you prefer. 
There’s no “one right way” to think about 
features and requirements, especially if you 
don’t want to waste lots of time arguing over 
definitions with your programmer buddies. 
You’re better off thinking about both features 
and requirements as the things your system 


for water as a type of terrain” (which is a 
pretty small, specific thing). In this approach, 
there's not really a big difference between 
what a feature is and what a requirement is. 
So these people see things a lot more like 
this: 


needs to do. If you want to consider features 
the “big picture” things, and requirements the 
“smaller, more detailed” things, that’s OK... 
just don’t get into any barroom fights over it, 
alright? 



Ih this 

di lot of 
overlap ih whoi-t a 
-Pcatu\rc is, olhd what 


a \rc^ui\rcrwCh-t is. The 
七 wo i^o\rc o\r 

less ih-tc\rdhcihgcablc. 
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no value, no use case 



OK, so weve got the feature and 
requirement thing figured out. Now we can 
write some use cases, right? 



Use cases don’t always help 
you see the big picture. 

When you start to write use cases, you’re 
really getting into a lot of detail about 
what the system should do. The problem 
is that can cause you to lose sight of the 
big picture. In Gary’s game system, we’re 
really not ready for a lot of detail... we’re 
just trying to figure out what the framework 
actually is at this point. 

So even though you could start writing use 
cases, that probably won’t help you figure 
out exactly what you’re trying to build, 
from the big-picture point of view. When 
you’re working on a system, it’s a good idea 


Always defer 
Jetaiis as long 


to defer details as long as you can... you 
won’t get caught up in the little things when 
you should be working on the big things. 


as you can. 



If we did write use cases for Gary’s game 
system, who would the actors be? 
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solving really big problems 


So what are we supposed to do now? 
You’ve been telling us we need to know 
what the system is supposed to do for like 
200 pages now, and suddenly use cases 
aren’t a good idea? What gives? 


O 


You still need to know 
what your system is 
supposed to do... but you 
need a BIG-PICTURE view. 

Even though use cases might be a little too 
focused on the details for where we are in 
designing the system right now, you still 
need to have a good understanding of what 
your system needs to do. So you need a 
way to focus on the big picture, and figure 
out what your system should do, while still 
avoiding getting into too much detail. 




Ever hear that a picture is 
worth a thousand words? 

Let's see if we caw show what 
the system is supposed to do. 
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from use cases to use case diagrams 


Use case diagrams 

Sometimes you need to know what a system does, 
but don’t want to get into all the detail that use cases 
require. When you’re in a situation like this, a use case 
diagram could be just what you need: 


以 : 3 仏 m 如 

^ ihc sysi^ c /,, 


OX is 
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solving really big problems 


OK, this is just plain stupid. What 
good does that diagram do us? Do we 
really need to draw a picture to figure 
out that game designers are going to 
create and modify games? 


0 


o 


Use case diagrams are the 
blueprints for your system. 

Remember, our focus here is on the big 
picture. That use case diagram may seem 
sort of vague, but it does help you keep 
your eye on the fundamental things that 
your system must do. Without it, you could 
easily get so caught up in the details of how 
a designer creates a new game that you 
completely forget that they need to actually 
deploy that game. With a use case diagram, 
you’ll never forget about the big picture. 



But what about all those 
features we worked so hard to figure 
out? They don’t even show up on the 
use case diagram! 


o 



Use your feature list to 
make sure your use case 
diagram is complete. 

Once you have your features and a use case 
diagram, you can make sure you’re building 
a system that will do everything it needs to. 
Take your use case diagram, and make sure 
that all the use cases you listed will cover 
all the features you got from the customer. 
Then you’ll know that your diagram —— the 
blueprints for your system —— is complete, 
and you can start building the system. 
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map your features to your use case diagram 


Feature Magnets 


It’s time to match up the game framework's features to the use cases in your use 
case diagram. Place the magnet for each feature on the use case that will handle 
that feature. If your use case diagram is complete, then you should be able to 
attach each feature magnet to a use case on your diagram. Good luck! 


ttcvc s ouv vasc tasc 
Jfov ouv system- 


Create New Game 



o 


/\ 

Game Designer 


Wcvc s the list o( 

-Pcatuvcs wc 

b 把 k oh page Z^Z 


up with 




Modify Existing Game 



^^^Deploy Game^^^ 


should kc 
use 

m system- 


Gary's frame System Framework 

Feature list 


1. The framework supports different 
types of terrain. 

2. The framework supports different 
periods, including fictional periods li 
sci-fi and fantasy. 

5. The framework supports multiple 
types of troops or units that are gawf 
specific. 

4. The framework supports add-on 

modules for additional campaigns or 
battle scenarios. ■ 

5. The framework provides a board wad? 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose 
turn it is, and coordinates basic 
movement. 


The framework supports 
different types of terrain. 
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The framework supports 
different time periods. 

The framework supports 
multiple unit types. 

The framework supports 
add-on modules. 


The framework provides a 
board made up of tiles, each 
with a terrain type. 

The framework keeps up 
with whose turn it is, and 
coordinates basic movement. 


J 


iirc ^ 3 h ^is. 

































solving really big problems 



e no . 

Questions 




So an actor is a person that uses the system? 


A: An actor is actually any external entity (it doesn’t have to be 
a person) that interacts with the system. So in a cash machine, you’d 
obviously have a person that uses the system as an actor, but you 
might also have the bank as an actor, because it deposits money in 
the system. If it's not part of the system but acts on the system, it’s 
an actor. 

What’s the box around everything for? And why are the 
actors outside of the box? 

The box shows the boundaries of the system. So you have to 
code up everything inside the box, but you don’t have to worry about 
the stuff outside the box. The actors—the game designers using your 
framework—are outside of the box because they use your system; 
they’re not part of it. 




And each circle is a use case? 


A! Right. That’s part of why use case diagrams are great for 
getting a handle on the big picture: they can show you multiple use 
cases, and how all those use cases work together to do really big 
tasks. It also helps you avoid getting into details about a particular 
requirement too early (like now, when you should be worrying about 
the overall system design). 




I’ve seen use case diagrams with lines marked with 
«include» and «extend». What’s that about? 

A! UML and use case diagrams do define ways to specify what 
kinds of relationships exist between use cases. So you could say 
that one use case includes another, or that one use case extends 
another. That’s what the 〈〈 include 〉〉 and 〈〈 extend 〉〉 
keywords mean. 

However, it's easy to spend a lot of time arguing over whether a 
use case extends this use case, or includes that one. And suddenly, 
you're spending your time on how a tile can support mountains or 
units need to carry a backpack, instead of focusing on the bigger 
picture. You can use 〈〈 include 〉〉 and 〈〈 extend〉〉, but 
it’s really not that big of a deal, and those keywords should never 
distract from the overall design process. 




So use case diagrams are more about a general picture 
of the system than including lots of little details? 

A! Now you’ve got it! If you’re worrying too much about 
what to call a use case, or whether you should use a particular 
relationship between use cases, you’ve lost sight of the big picture. 
Use your use case diagrams to get a clear 10,000-foot view of your 
system, nothing more. 


Thanks for all the info, but can we get 
back to that Feature Magnets exercise? 
rm stuck trying to match one of the 
features to a use case... 
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we have a feature problem 


ii's a 

S 



i- Feature Magnets Solutions 


It’s time to match up the game framework’s features to the use cases 
in your use case diagram. Were you able to find a use case for each 
feature in the game framework? 




The framework provide _ 

board made up of tile! The framework supports ■ 
with a terrain type. | different types of terrairi^ 

"""framework supports 


3te N( 


The framework supports 
multiple unit 


o 


八 

Game Designer 


The framework supports 
add-on modules. 


代 Wed spe^lly ^ \ 



Modify Existing Game 


Deploy Game 


K 

如 6ould also V^avc 


Put there's owe feature still left... 
what up with that? - 

There’s probably one feature you had some 
trouble placing on the use case diagram. 
Think about this feature carefully: it’s really 
not something the game designer directly 
interacts with or worries about, because the 
functionality is already taken care of. 

So how is this feature related to the system? 
And what actors are involved? And are we 
missing some use cases in our diagram? 

What do you think? 





V\fe ky\o>w tW»s a 
JfcaWc, Wt ^7 

m ouv feW— 仫 . 
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solving really big problems 


The Little Actor 

A small Socratic exercise in the style of The Little Lisper 


What system are you designing? 

A game framework, duh! 

So what is the point of the framework? 

To let game designers build games. 

So the game designer is an actor on the system? 

Yes. I’ve got that in my use case diagram. 

And what does the game designer do with the 
framework? 

Design games. I thought we established that! 

Is the game the same as the framework? 

Well, no, I suppose not. 

Why not? 

The game is complete, and you can actually 
play it. All the framework provides is a 
foundation for the game to be built on. 

So the framework is a set of tools for the 
game designer? 

No, it’s more than that. I mean, the feature 

I’m stuck on is something the framework 
handles for each individual game. So it’s 
more than just tools for the designer. 

Interesting. So the framework is part of the game, 
then? 

Well, I guess so. But it’s like a lower level, 
like it just provides some basic services to the 
game. The game sort of sits on top of the 
framework. 

So the game actually uses the framework? 

Yes, exactly. 

Then the game actually uses the system you’re 
building? 

Right, that’s just what I said. Oh, wait... 
then... 

...if the game uses the system, what is it? 

An actor! The game is an actor! 
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actors aren’t always people 


Actors arc people, too 
(well wot always) 


It turns out that in addition to the game designer, 
the game itself is an actor on the framework you’re 
building. Let’s see how we can add a new actor to our 


use case 


diagram: 




Do these new use cases 
take care of the feature we 
couldn’t find a place for? 


The framework keeps up 
with whose turn it is, and 
coordinates basic movement 
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solving really big problems 


Use case diagram... check! 
Features covered... check! 

With a new actor in place, we can finally take our use 
case diagrams and our features, and match them all up. 


」The framework supports 
The framework _ 

board made up of til^ supports 
with a terrain type .| different types of terrain^ 


lewGame 


I The framework support 寻 
multiple unit types. 


I The framework supports 
I add-on modules. 


Create Board 


八 

Game Designer 


r 


Mos*t <^f *tKc 
-features vcla*tc 
*to y/K 3 "t 
dcsi^cv* docs 
i\\t -fv-amcv/ov-k. 


Modify Existing Game 


Move Units 


The framework keeps up 
with whose turn it is, and 

ic movement 


)eploy 


Add/Remove 
Units 


HevVs OUV a 己 *toV", 

also 

uses 

duvm^ ^amcplay- 



o 


I 八 

The Game 

Tiic mev/ use CSses 
asso^idied v/rtii 七 he 
-take care of 
VJC had 


Sharpen your pencil - 

^ k. That last feature is still a little funny... 


wSh fr r ework ke 印 s up 

lth wh °se turn it ^ 

coordinates hw ' nd 

The second part of that last feature, about movement, fits in with the “Move Units” use 


case... but what about keeping up with whose turn it is to movey it seems MKe mere s 
something still missing from our use case diagram. It’s your job to figure out two things: 

1. Who is the actor on “The framework keeps up with whose turn it is?” 


2. What use case would you add to support this partial feature? 



* Ma^r 


A . 鮮 awv 
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completing the use case diagram 


Sharpen your pencil 

、、 answers 

That last feature is still a little funny... 

The second part of that last feature, about movement, fits in with the “Move Units” use 
case... but what about keeping up with whose turn it is to move? It seems like there’s 
something still missing on our use case diagram. It’s your job to figure out two things: 

1 ■ Who is the actor on “The framework keeps up with whose turn it is?” 

The game is still the actor:" it's using the framework to_ 

handle managing whose turn it is. 



2. What use case would you add to support this partial feature? 

We need a use case for "Take Turn" where the framework 
handles basic turn duties, and lets the custom game handle 

the specifics of that process. 




us c 
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solving really big problems 


So what exactly have we dowc? 

You’ve got a list of features that Gary’s game system 
framework needs to support, and that tells you all the 
major pieces of the system you need to build. This is 
a lot like the requirements list you built way back in 
Chapter 2 for Todd and Gina’s dog door... except it 
focuses on the big picture. 

Use a feature or requirement list to 
capture the BIG THINGS that your 
system needs to do. 


Once you’ve got your features and requirements 
mapped out, you need to get a basic idea of how the 
system is going to be put together. Use cases are often 
too detailed at this stage, so a use case diagram can help 
you see what a system is like at 10,000 feet... kind of like 
a blueprint for your application. 

Draw a use case diagram to show 
what your system IS without getting 
into unnecessary detail. 


八 

Game Designer 


tteves our ^ tase 

SO 工 


OVAV 




Create New Game 


Modify Existing Game 


Deploy Game 


\ C，S ou,r list.. ih c 

$ysi ^ d <> 


备 ary's System Framework 

Feature List 

1- The framework supports different 
types of terrain. 

么 The framework supports different time 
periods, including fictional periods like 
sci-fi and fantasy. 

炙 The framework supports multiple 
types of troops or units that are ga 晰 e- 
specific. 

4. The framework supports add-on 
modules for additional campaigns or 
battle scenarios. 

5. The framework provides a board made 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose 
turn it is. 

^The framework coordinates basic 
movement. 


Create Board 


Take Turn 


^ ^ _ 1 



( Move Units 一 " 




o 


The Game 


Add/Remove 

Units 
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speaking the customer^ language 

Cubicle Conversation 


o 


Isn’t it about time we started 
actually talking about code? I mean, I get 
that we need a feature list, and use case 
diagrams, and all that, but at some point 
we have to actually build something, 

you know? 



Frank: I don’t know, Jim. I think we have been talking about code. 

Jim: How do you figure that? I mean, what line of code is 
“framework supports different types of terrain” really going to turn 
into? 

Frank: You’re talking about those features we figured out, right? 
Well, that’s not just one line of code, but it certainly is a big chunk of 
code, right? 

Jim: Sure... but when do we get to talk about what classes we need 
to write, and the packages we put those classes into? 

Frank: We’re getting to that, definitely. But the customer really 
doesn’t understand what most of that stuff means... we’d never be 
sure we were building the right thing if we started talking about 
classes and variables. 


Domain analysis 
lets you ckeck 
your designs，and 
still speak tke 
customer’s: language. 


Jim: What about class diagrams? We could use those to show what 
we’re going to code, couldn’t we? 

Frank: Well, we could... but do you think the customer would 
understand that much better? That’s really what domain analysis is 
all about. We can talk to the customer about their system, in terms 
that they understand. For Gary, that means talking about units, and 
terrain, and tiles, instead of classes, objects, and methods. 
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solving really big problems 


Let's do a little domam awalvsis! 

Let’s put all these things we’ve figured out about the game system 
together, in a way that Gary, our customer, will actually understand. 
This is a process called domain analysis, and just means that we’re 
describing a problem using terms the customer will understand. 


⑼ d—Ws. 



TWlS 冰 C ， 


is 


■> 


Gary's ^ame System Framework 

Feature List 

1. The framework supports different 
types of terrain. 


2. The framework supports different time 
periods, including fictional perioj^ 

_sci-fi awd fantasy. 1 rlZpil 

$• The framework supports multiple 

of troops or units that are gamc- 



3— systems. 


I types of 
^ 1 4 specific. 

fran 


framework supports add-on 
modules for additional campaigns or 
battle scenarios. 

5. The framework provides a board made 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose 
turn it is. 

1 The framework coordinates basic 
movement. 


" ScJolar'sCorfief 



(Jomdm dhdlysis. The process of 匕。 "e 匕七叫 , 

ov^hizjh^, dhd V^rcscjoim^ V"dev3h*b o-f d 

domaih) based *thc s-tudy of sys-tc^s a^d 

■theiv development his-to\rics, knowledge dap*tu\rcd -fv-om 
domdih C^pc\rts, Uhdc\rly*m^ *thco\ry, dhd 
■bcdhholo^y v/rtiVm 3 domdm. 
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everyone loves a happy customer 


What most people give the customer. 



Unit 


Unit.java 


type: String 
properties: Map 


setType(String) 
getType(): String 
setProperty(Strin 
getProperty(Strin v 


hese avc ^lass ahd package 
a 叫 dodc-lcvcl details about how 
yoi/ll build ^a\rys -Pv-amcwo^k. 




because a 

^VO^vawmCV-! Vou d»dr> 

sjeak hi! 1 3 鄉 30 ^. 




What weYe giving the customer. 




Gary's 备 ame System Framework 

Feature List 

1. The framework supports different 
types of terrain. 

1 . The framework supports different time 
periods, including fictional perioj^ 
sci-fi and fantasy. £ ”4 糧 , 

^.Thl framework supports multiple 



I 


I ty es of troops or units that are game- 
specific. 


4. The framework supports add-on 
modules for additional campaigns or 
battle scenarios. 

5. The framework provides a board wade 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose 
turn it is. 

7 The framework coordinates basic 
wovewewt. 
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0\ay -Pcatuv-c 

ih 

"the dus-fcomey" 
uhdcv-s-tahds. 


Very cool! That*s exactly what I 
want the system to do. 





^avVs tilled) 

u^dev-sta^d ^atvou ve 

办 d do 

N^aUc 如 















































solving really big problems 


Now divide and conquer 


With the customer onboard, and a nice completed set 
of blueprints, you’re ready to start breaking up your big 
problem into different pieces of functionality — and then 
you can use what you’ve learned already to tackle each of 
those pieces of functionality, one at a time. 


Hcrcs a 代峙 dyraWm ? 

some oU“ 〜 代 


1 046 


Time Periods 

We may not need to do 
much here... as long as we 
support different terrains, 
unit types, and weapons, this 
should come naturally. 


We need a way to represent a 
basic unit, and let the game 
designers extend that to create 
game-specific units. 


p 亡 ah bircak -the 


p 一 unt h\rac 

dowh i h -to SCV( 


Clral 


The framework needs to 
have a basic tile, and each 
tile should be able to support 
terrain types, units, and 
probably handle battles, too. 



Terrain Types 

Each tile should support at 
least one terrain type, and 
game designers should be able 
to create and use their own 
custom terrain types, from grass 
to lakes to asteriod dunes. 


^ — —9-bl, P ^ s . 
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breaking up the big problem 


TKe Big Break-Up - 

It’s time to break up our big problem — Gary’s game framework — into lots of smaller 
pieces of functionality. You’ve already seen how we can divide the game and its features 
into some basic groups of functionality, so you’re already well on your way. 

Below are the features and diagrams we’ve been using throughout this chapter to show 
what Gary’s system needs to do. You need to look at these, and figure out what modules 
you want to use to handle all this functionality, and how you want to split the features 
and requirements up. Make sure your modules cover everything you think the game 
framework will need to do! 


Gary's ^ame System Framework 

Feature List 

1. The framework supports different 
types of terrain. 

2. The framework supports different time 
periods, including fictional periods like 
sci-fi and fantasy. 

$• The framework supports multiple 
types of troops or units that are game- 
specific. 

4. The framework supports add-on 
modules for additional campaigns or 
battle scenarios. 

5. The framework provides a board made 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose 
turn it is. 

1 The framework coordinates basic 
movement. 



Wcirc S ihc boa\rd io 

you of Somc ^ 

ihe ^ 3 J olr io 4^us 

bui -this 


You y\ccd bo addvcss all 
-fcatuvcs *m 七 he sys 七 … 


well as the 

M^Wiy i 3ld oui jh 
you^r use (iasc diagv^. 
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solving really big problems 



added a module 

9^ Med. This would 
^ vcpvcschtmg 

^°°P^ 扣 ahd vcla-tcd 

+uhdtiohali-ty would 30 . 

V TV W ^ c/ l£W 

module sU W 。卜 

\ 




ddh ddd mo\rc modules i-f you 
Y\ttd, ov use less modules y/c^vc 
provided. I*t’s dll up *to you! 




We have BIG problems, 
and I just carVt handle them. Ifs 
time to break up. 


o 


A 









m 
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lots of small problems 


Our Big Break-Up - 

Here’s what we did to handle all the features of Gary’s 
system, and to break the big problem up into several 
smaller, more manageable pieces of functionality. 




The bod\rd module 
hdhdles the bodv*d 

tiles, -tc\r\raih, av\d 
othev- classes \rclaicd 
"to the d^iual 

boav-d used ih 


TWis takes cart 
-bv-oo^s, avw>cs, ay\d sll 
i\sc uyvits used rn a %… C. 


— mi 儒 



IA/C dV^osc HOT V^avc a module 

U Wvam, ov tiles, smdc tV^cvc 

v/ould 0^7 kc o^c OV W 
七 Wc modules. Ustcad, htd 
all m*to i\st Boavd module- 


C w 

usiha ^ ^ ,, 

卞 u_ sses dH 

^ d by des ert bc 

3— W p，op 

ds C ^ 3— 




|^ s alv/dvs a ^ood idea *to Viavc a IXWrbes 

module, -to short -tools a^d Viclpcv dlasses 
i\\^i arc slaved across modules. 



Controller 

- 


o 


"> 


ttc^s y/V^ew W ‘die 如 

ca ^ ? la7cv, kas»t 眯。 vcw 此 a”d 
else elated -to keepm^ a attualW 
— % TW，s module »s so^r-t tV^c Va+U 
to/^or tKc -tKat dcsi^crs ⑽ ate. 



There’s no single RIGHT 
answer to this exercise! 

It’s OK if your answers don’t match up 
with ours exactly. There are lots of ways 
to design a system, and this is just the one we chose. 
What you do need to worry about is that you’ve covered 
all the features and use cases with your design, and that 
it makes sense... you don’t want a module to have just 
one class in it, or one that will have one or two hundred. 
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solving really big problems 



To^v ^ ^ a lot about 
makes -fov a killer ^a^c, but 
V^cs v>ot 7£u)r 


>wCV" 


Pow't forget who your 
customer really is 


It might seem like Tony has a good point... until you 
remember who the customer for Gary’s game system 
framework really is. Your job is to write a framework 
for game designers, not to create actual games. Every 
game’s user interface will be different, so it’s up to the 
game designer to take care of graphics, not you. 

Domain analysis helps you avoid 
building parts of a system that 
aren’t your job to build. 



"This is so^c-thihg 
七 hat the 
dcsijhcir would 

〜汾 (:匕 .. ho 七 

yowr irespohsibili-ty. 



Take a close look at the modules and groupings in the 
game system framework. Do you recognize a commonly 
used design pattern? 


Wtrts a V^m-b you Head 
Pcs 吵 Patter veadevs. 
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model-view-controller 


You know, once the game designer 
adds in a Graphics module, this looks an 
awful lot like the Model-View-Controller 

pattern. 


O 



Most people -to 七 Wl 


s 


If s the Model-View-Cowtrollcr Pattern! 




the game 

4o^t\rolle\r -that wcVc 
goihg "to y/\ritc. li 
handles basid tuv-hs 
3hd -PiguHhg out what 
i^ccds io hdppeh with 
boav-ds, uhi-fcs ； d 



Graphics 




祕:工二， S 

口二 4: 

心身 ec 

SO〆 咖 崤 



class Pla: 
play(){. 
rip(){} 
burn(){} 


Model 




Controller 


^o\\^ 

C0 n\9^ teS 
P ode\ 
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These vcally Ao^i 
• ，山 払 c IA\IC pa 七 W 
W 七 ^cyVc still part 

oJf i\\t 〒 W. 


dcs'^irvcvs 

da 矜 c%*tc^d *bWis 

module 
ovm —e -邛 
6ov>*brollcv"> W 七 
七 Wis module ' s s>\)\\ 
七 V^c y we 

6 ov>*bv-ollcv-. 


























solving really big problems 



m' 





Yovav Code, ^ ^ 
孙 d 外， d 



What’s a design pattern? 
And how do I use owe? 


We’ve all used off-the-shelf libraries and frameworks. We take them, write some code against their APIs, 
compile them into our programs, and benefit from a lot of code someone else has written. Think about 
the Java APIs and all the functionality they give you: network, GUI, IO, etc. Libraries and frameworks go 
a long way towards a development model where we can just pick and choose components and plug them 
right in. But... they don’t help us structure our own applications in ways that are easier to understand, more 
maintainable and flexible. That’s where Design Patterns come in. 

Design patterns don’t go directly into your code, they first go into your BRAIN. A design pattern is just 
a way to design the solution for a particular type of problem. Once you’ve loaded your brain with a good 
working knowledge of patterns, you can then start to apply them to your new designs, and rework your old 
code when you find it’s degrading into an inflexible mess of jungle spaghetti code. 



\/ovA- 




sf V 


9-lj-o 亡 scl<c 
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confused about design patterns? 


O 


I haven’t read Head First Design 
Patterns, and I*m still a bit fuzzy on 
exactly what a design pattern even is. 
What should I do? 



Keep going! Design 
patterns are one of the 
last steps of design. 

It’s OK if you’re not familiar with design 
patterns. Design patterns help you take 
those last steps of design —— once you’ve 
used OO principles like encapsulation 
and delegation to make your software 
flexible, a well-chosen design pattern can 
add just that extra bit of flexibility to 
your design, and save you some time, too. 

But it’s no big deal if you’re not familiar 
with design patterns. You can still work 
through this book, and get a handle 
on really solid design. Then, we’d 
recommend you pick up Head First 
Design Patterns, and see how other 
people have been handling some classic 
design problems, and learn from them. 
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solving really big problems 


Feeling a little bit lost? 

We’ve done a lot of things in this chapter, and some of 
them don’t even seem to be related... 

— Gathering features 

— Domain analysis 

— Breaking Gary’s system into modules 
—Figuring out Gary’s system uses the MVG pattern. 

But how does any of this really help 
us solve BIG problems? 

Remember, the whole point of all this was to get a 
handle on how to deal with really large applications — 
like Gary’s game system framework — that involve a lot 
more than some basic design and programming. 

But here’s the big secret: you’ve 
already done everything you need to 
handle Gary’s BIG problem. 
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you know how to solve small problems 

The power of 00 A 备 P 
(and a little common sense) 


! •一 

Gary’s Games pro. 


Gary’s Games 

Vision Statement 


-amp provides frameworks that game designers can use to 
create 咖杨 ed strategy games. Unlike arcade-style shoot-em^ 
Tmes and games that rely on audio and video features to engage the 

player, our games will focus on the techmcal details of strategy and 
Ltics Our framework provides the bookkeeping details to make 
building a particular game easy, while removing the burden of coding 
repetitive tasks from the game design. 

The game system framework (GSF) will provide the core of all of 
Garyl Ganges. It wffl be delivered as a library of classeswrthawell- 

defmed API that should be usable by all board game development 

project teams within the company. The framework wJl provide standar 
capabilities for: 

♦ defining and representing a board configuration 

♦ defining troops and configuring armies or other fighting units 

♦ moving units on the board 

♦ determining legal moves 

♦ conducting battles 

♦ providing unit information 

TheGSFwffl simplify the task of developing a turn-based strategic 
board game so that the users of the GSF can devote the ir ti me to ^ 
implementing the actual games. 




叫 ou*t 

欤 is irathev vague, 

visioh 

siatcmcht Kow thats 
a problem. 


Ov\tt 

窗 t ertaitd a 

use cast d'»ayam *b us 


fe usienea 10 me cusiomer. 



Game Desigr 



❺ we drew up mueprints tor 
the system we’re building. 


备 aryls ^amc System Framework 

Feature List 

1. The framework supports different 
types of terrain. 

The framework supports different time 
periods, including fictional periods like 
sci-fi and fantasy. 

多 • The framework supports multiple 
types of troops or units that are game- 
specific. 

4. The framework supports add-on 
modules for additional campaigns or 
battle scenarios. 

5. The framework provides a board made 
up of square tiles, and each tile has a 
terrain type. 

the framework keeps up with whose 
turn it is. 

Z The framework coordinates basic 
movement. 


(Xsnr\^ dow»3iy\ 扣 abys'is, >wc 

made suve u^dev-s^^d 
y/Ka*t ^av-y v/a 士 d Wis 
sys*tcw\ *bo do. 


❺ We made sure we 

understood the system. 
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We 

! ,st . ,h wc wcv-c able 

sr * ?^Jo^ 

，hd ^3l -Puh^iohaliiy. 




I Controller " 

_3 


❹ We broke the big problem up into 
smaller pieces of functionality. 


solving really big problems 


W!c cvcy\ *book a dcs'i^y\ 

>wc already 

uy\dcv-s*tair\d, a^d applied 
\i bo ouv- sys-tew'- 




Look! You already know how to 
solve these smaller problems, using 
everything youVe already learned 
about analysis and design... 



...and you can even figure out 
how to apply the MVC pattern 
from Head First design Patterns. 



M - V - C 




class Plaj 
play(){} 
ripOU 
burn() {} 


Model 




Controller 




❺ We apply design patterns to help 
us solve the smaller problems. 



ConfflatolaRons? 

You ve turned a BIG PROBLByt 

into a bttncli of smaller problems that you 

already l^now how to solve. 
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ooa&d toolbox 



Tools for your 00A 备 P Toolbox 

You’ve taken on a huge problem, and you’re still 
standing! Review some of the things you’ve learned 
about handling big problems, and then you’re ready 
for the return of the OOA&D crossword puzzle. 


Bi^ Pvoblgms 


6(ood 
Y/ov-ks l*»k(| 

Make suvj 
by devel<l 

Use Y ouV 
七 Wi 呼 y 

Youv* usc| 
ov missn 
have- 

Youv 

^\toy/) <m 


lAfell-dcst^ 
d^d c%*tcv>d| 

Use basid. 

a 灼 d 

mo\rC -flcWtl 

\( a dcs'i^i 
|T| New 

/our 


Make suv-c 

y| 

OHt Tttl, 
Always st 

move 
li 心己 '/de. 


Listen -to -the 〜 s*tow^\r, 扣 d ou 七 

>wha*t they >wa^*t you -to build. 

Put -toje-thev a -fcaWc list, *m la^juajc 

■the dus*bomC\r u 灼 d^rs*ta 灼 ds. 

Make suve youv -feaWes art what the 
d.us*bomcv ad^ually 

Create klucf\r*m-bs o-P the system usmj u 
cast did^dms (av\d use casts). 

Bv-cak the bij system uf *m*to lots o( 
smdllev* sedtio^s. 

Apply dcsi^ *to the smaller 

scd.*tioy\s o-f system. 

Use bdsid OOMV f^rmdiflcs *to design ai 
Code t^cM smaller stcho^ 


BULLET POINTS 


^o*b d v/holc 灼 CV/ 

tatc^ov-y o-f 七 etVmi'ues 
y/e leaded abou 七 _m 
七 Wis 乩 after. 


00 Pvihdiples 

Ehdapsula*tc what vav-ics. 

Code -fco 'm-tev-Pade vathev 
*thar\ *fco implcimcr\*t 3 *tioy\. 

Eadh dass m youv afflidaiioh 
should Kavc or\ly ov\t veasoh *fco 

Classes avc about behavior a^d 
-Puhd*tiohali*ty. 


■ 


■ 


■ 


■ 


The best way to look at a big problem is to view it as a 
collection of smaller problems. 

Just like in small projects, start working on big projects 
by gathering features and requirements. 

Features are usually “big” things that a system does, 
but also can be used interchangeably with the term 
“requirements.” 

Commonality and variability give you points of 
comparison between a new system and things you 
already know about. 


■ 


■ 


■ 


■ 


Use cases are detail-oriented; use case diagrams are 
focused more on the big picture. 

Your use case diagram should account for all the 
features in your system. 

Domain analysis is representing a system in language 
that the customer will understand. 

An actor is anything that interacts with your system, but 
isn’t part of the system. 
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OOA&D Cross 

It’s time for another left-brain workout. 
Below is a puzzle with lots of "blank 
squares ； to the right are some clues. You 
know what to do, so go for it! 



Across 

Z. Thii 1o lh& LLiilDmtr m 

their language (Z words} 

3. You ctm use your f m 言 ire list lo nvaka sure 

ynnr rtin^rnm thk 

h IKp. rinn't nlwny 1 ； Kp_lp ynir thi< (2 

wrarJs). 

7. T^iesa aren't aKway^ people. 

A featu''* a _ _de^cHpi^sn &f 

meth^ng a jy^'tem needs to da. [S wcurdis) 

10. Art V^andday'^ M rtal l! la^t name 

12. A u^c Jiuqrum ut;ts as lh^ for yvur 

SySl cm. 

14 . Vou can figure out These based cn yaur 
fculures. 

Thr< \< thp. mpiiKnrft af hnw thrn^< nr« 
fiim^Par. 


I^ 0 WP 1 

L An ovul in u cmie d iugrum rapr &Stin E S one 

of these, 

2 Wp /ippJiftd nmX rtf ter. yaur < 

framework, 

4. The measupe of how th(P^£ arc different, 

£.. Vfliy fkciuldi sahe a big prabl^m by dain^ this 
to \i (3 ward5) 

9. you can fiiqure emt a System'^ featured by 

_„ Id thtE, llesS om&r. 

11. You solve big probPems rha__you 

^alv£ ^inoll probfejrvs words). 

I'A Dftfftr fhp<p. Inng pn«ibJft 
15. We iwaSn't the ouStomc 111 . 
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crossword solutions 




Excise 

、 • 

SpLvtlPHS 
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7 arcjiitecture 


Bringing Order to Chaos 



right somewhere! You know how to break your application up into lots of 
small problems, but all that means is that you have LOTS of small problems. In 
this chapter, we’re going to help you figure out where to start, and make sure 
that you don’t waste any time working on the wrong things. It’s time to take all 
those little pieces laying around your workspace, and figure out how to turn 
them into a well-ordered, well-designed application. Along the way, you’ll learn 
about the all-important 3 Qs of architecture, and how Risk is a lot more than just 
a cool war game from the ‘80s. 


this is a new chapter 
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where do we start? 


Feelmg a little overwhelmed? 


So you’ve got lots of small pieces of functionality that you know 
how to take care of... but you’ve also got use case diagrams, 
feature lists, and a whole lot of other things to think about. 


qary's frame System Framework 

Feature List 

l.Thc framework supports different 
types of terrain. 

2 The framework supports different time 
periods, including fictional periods like 
sci-fi and fantasy. 

多 .The framework supports multiple 
types of troops or units that arc game- 

specific. 

4. the framework supports add-on 
modules for additional campaigns or 
battle scenarios. 

5 . the framework provides a board made 
up of square tiles, and each tile Has a 

terrain type. 

6. fhc framework keeps up with whose 
turn it is. 

7 the framework coordinates basic 
movement 






n 1 —KHii 

&a_ 


m. 


Controller 



..individual modules to code. 


OK, even if I do know how to 
handle all these individual pieces, where 
the heck am I supposed to start? Can 
you at least tell me what to do 

FIRST? a ^ Q 




Rcw'CW'kcV- ouv- 

Wtrts 一 v/e left Wn 

kd^k m 七 
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architecture 



...high-level views oHAnianATe need to build... 



Gary’s Games 

Vision Statement 


雜 


Se tunT H 68 frameworks game designers can uslto 
: ate turn-based strategy games. Unlike arcade-style shoot-'enl^ 

^ and g am e S that rely on audio and video features to engage the 

Player, our games will focus on the technical details of strate^fnd 

acacs. Our framework provides the bookkeeping details to ie 
p he f^ C SySt 7 framework (GSF) will provide the core of all of 

deZedAHth tr t ，祕 ―一 
nroiect f that be usable by all board game development 

SSS: COmPany - The provide standard 

♦ Defining and representing a board configuration 

♦ Defining Units and configuring armies or other fighting units 

♦ Moving units on the board 

♦ Determining legal moves 

♦ Conducting battles 

♦ Providing unit information 

boa e r ?f WiU T lif r hetaSkof de —— a turn-based strategic 
board game so that the users of the GSF can devote their time to 
implementing the actual games. 




■the customers vl 



Do you think it matters what you should try to do first? If 
you do, why? And what would you work on first? 
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the power of architecture 

Wc 賺 d aw architecture 

It’s really not enough to just figure out the individual pieces of a 
big problem. You also need to know a little bit about how those 
pieces fit together, and which ones might be more important than 
others; that way, you’ll know what you should work on first. 


Architecture is your 


lAfe already *tW»s... 

V^clps us 

des'i^ -tKcsc k'«5 systems. 

c —— _ design structure 


J 


and highlights the 

most important 


parts of your app, and the 


0\A^ 


U5 « (^asc 


i he 

•“户 II P^eUy 


relationships 

between those parts. 


ihis j s 

“耗二 “d.. 
now do wc 

+'9^^ ou-t 
S Vhos 士 

― 。七 hi so 

wc ^ build 
•those f>3^is o( 

oulr 外 p f ^si? 


"° dulcs 


^11 *tW»s is fav-*t'»tulavlY 
wpov-ta^*t v/Kc^ Y ouVc ⑽ 
y/l-tK O-tKcV- … Y ou 

Kave {p all uy\dcv-s*tay\d 
same av-tK'»*bct-tu\rc. 


—Se|lO! 9 I% - G©!?!!©? 



A^^^»*tcd*tu\rc is *thc o\r^dhiz^*tiohdl s*t\rud*tu\rc 
o-f d system, ihdludm^ i*bs dedomposi-bioh *m*to 'theiv* 

dohhCd*tivi*ty, *m-tc\rad*tion medhahisms, diad *thc ^uidm^ 
prihdiplcs dhd dedisiohs you use m *thc desi^h 

<Jc a system. 
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Architecture takes a big chaotic mess 


architecture 


be 哼七七 Wis 
You vc ^o*t lo*b 
•iw^orta^t diaya^s av\d 
fla^s, ku-t cvcv-y-tK'm^ is 
jus*t a Wy w'ess. 



I have no clue what to 
do with all of this stuff 


■㈣ :: f 管 ■L 


I 咖 conligunng armiaor other 
on Ihe board 


• moving uniu 
•dclcrmining ： 


_ ^ < 3 ^ 
㈣ < l5jr±^ ^ 




and helps us turw it into a well - ordered application 


丁 Wis \s >at 从 ， t.’’ ^ 



o 






Ail 

(i'ta^sws a^d 
^attcV'irvS 3 VC 

used -to W，ld 
i\\t dusfcowcv- 


—a 七 
七 \^ >/a 此 W 
Y/\*tWm 3 -fU'A'klC) 
yrcusaklc dcs ， 
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we J re still building great software 


You write great software the same 
way，whether you’re working on a 
small project，or a huge one. You can 
still apply the three steps we talked 
about way back in Chapter 1. 


this page the 

a ㈣ 域 . 


Wc know tWcc 

s-teps will us tackle tacM o\ 
七 kse mdividudl fictcs tiic 
system -fvamewovk. 



Controller 



Utilities 丨 

、 , — ■及 



w ^ 一 w 。， 

恤〜 sW 吖一 jjl 
㉗ 


㈣ 对 software ih | easy steps 


MclltC your 
software Joes vial tlie 

customer van Is il (i> — 土十匕 


%二兹 

.t j m** 




2 » Apply l>asic 
⑽ priiiciple5 to 
aJJ ftexiliilii 


fWdS hw ■产 

i&rt ^H-*w 

|pnJ W |r^|aUL 


^j 1 - 

**■ * 4 »idf 

i^. 

“iW 


3« Strive foi* a 
， maiiitaitiatle, 
**emaWe cfesign. 
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ReallynBiG application 



















architecture 


Ut'$ start with fuwctiowalitv 

The first step is always to make sure an application does what 
it’s supposed to do. In small projects, we used a requirements list 
to write down functionality; in big projects, we’ve been using a 
feature list to figure those things out: 


All 

art about 

svstcw "to d®) 
cm N^at ov 

▽att 代 ⑽ 7 ou uSC 匕 
W»ld svstcm. 


Gary's frame System Framework 

Feature List 

1. The framework supports different 
types of terrain. 

2. The framework supports different time 
periods, including fictional periods like 
schfi and fantasy. 

炙 The framework supports multiple 
types of troops or mU that are game- 
specific. 

4. The framework supports add - ow 
modules for additional campaigns or 
battle scenarios. 

5. The framework provides a board made 
up of square tiles, and each tile has a 
terraih type. 

6. The framework keeps up with whose 
turw it is. 

1 The framework coordinates basic 
movemeht. 


Put which of these arc 
the most important? 

Even if we know to start by focusing on 
functionality, we still need to figure out which 
pieces are the most important. Those are the 
pieces we want to focus on first. 


M’ll Come ba^k 
io these o-thc^* 
diajlrarhs dhd 
paUcirhs la-tcv-... 
but Hah-t how, 
^usihg 
solely oh the 
-Puh^tiohality of 
"the system. 






IE3 

1 i 



Controller 
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start with functionality 


Sharpen your pencil 

、 What do YOU think are the most important features? 

Even though our feature list has only seven things on it, there’s a lot of work 
in those seven features. It’s your job to figure out which features you think are 
the most important, and then in what order you’d work on those things. 


Gary's frame System Framework 

Feature List 

1. The framework supports different 
types of terrain. 

2. The framework supports different time 
periods, ihclud'mg fictional periods like 
sci-fi and fantasy. 

J.The framework supports multiple 
types of troops or units that are game- 
specific. 

4. The framework supports add-ow 
modules for additional campaigns or 
battle scenarios. 

5. The framework provides a board wade 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose 
turn it is. 

7 The framework coordinates basic 
movement. 


^ - ^ V>a^lc all 

^ - these but 

VA\> "bo 70U -t0 

) out ovdev 70U 

〆 should tV.Cm m. 


2 . 

3. 

4. 
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architecture 


Tke tilings 


m 


your 


application 
tkat are really 
important are 
arckitecttfrally 
significant, 
anct you skoulct 
focus on tkem 

FIRST. 



Wait a second... if 
architecture is about the relationships 
between the parts of an application, 
why are we talking about the individual 
parts? Shouldn't we be talking about 
how the parts work together? 


You gotta start somewhere ! 

It’s awfully hard to talk about the 
relationships between parts of a system if 
you don’t have any of the parts themselves. 
So say you wanted to talk about how the 
Board module interacted with the Units 
module: 


To figure out how these modules interact, 
you’d need to have at least the basics of the 
two modules in place first. 

So architecture isn’t just about the 
relationships between parts of your app; it’s 
also about figuring out which parts are the 
most important, so you can start building 
those parts first. 
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what is architecturally significant? 


The three Qs of architecture 


When you’re trying to figure out if something is architecturally 
significant, there are three questions you can ask: 




1. Is it part of the essence of the 

Is the feature really core to what a system 
actually is? Think about it this way: can you 
imagine the system without that feature? If not, 
then you’ve probably found a feature that is part of the 
essence of a system. 



\ 一 the 



does it mean? 


suggest \rcpb^ihg 
P^hi-ty 'w ， 


If you’re not sure what the description of a particular 
feature really means ， it’s probably pretty important that 
you pay attention to that feature. Anytime you’re unsure 
about what something is, it could take lots of time, or 
create problems with the rest of the system. Spend time on 
these features early, rather than late. 


3. How the "hcck" do \do it? 

Another place to focus your attention early 
on is on features that seem really hard to 
implement, or are totally new programming 
tasks for you. If you have no idea how you’re 
going to tackle a particular problem, you 



better spend some time up front looking at that feature, so it 


doesn’t create lots of problems down the road. 
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architecture 


BE 如 J[vchii^ct 

To tire ri^ht, you’ll find tire 
feature list we figured out in the 
last chapter. Your job is to play 
like you’re tire arcliitect, 
and figure out what’s 
arcliitecturally significant 
by using lie lliree Q3 of 
arcldtecture we just talked about. 





存 ary $ frame System Frawigwnr^ 
Feature List 

I 1. The framework supports different 
types of terrain. 

么 The framework supports different ti_ 

P erio ^ iwcladiwg fictional periods like 
sci-fi awd fantasy. 

多 • The framework supports multiple 

types of troops or units that are game- 
specific. 

4. The framework supports add-ow 
►nodules for additional campaigns or 
battle scenarios. 

5 The framework provides a board made 

叩 of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose 
turyi it is. I 

Z The framework coordinates basic I 
movement. 


What’s significant? 


Why? 



CKctk a^d see Kov/ dose youv- 
a^y/c^rs Kc^rc ma-bK uf -to v/^at 70U 

y/VO*tc doYJY\ OY\ ^0- 


^iic doy/h 

thvee applies 
(you Qh wv-i-tc 
-thah ohc, 
■(you heed io) 
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figuring out whafs significant 


BE tlie J[vchii^ct 
Solutions 

To the ri^ht you’ll find 
ike feature list we 
figured out in tiie 
last chapter. Below are 
the tilings we were 

arcliitecturally significant, 
and wliich of tire tiiree Q3 we 
used to make our decisions. 





亀 




What’s significant? 

The board -for 七 he 

uhi-bs_ 

The -framework doo\rd*ma*tcs bdsid r^ove^eht 


Wlc dcdidcd t^a*t tV^c 
board >^ds tov-c *to 
^3w\C ••- y/i*t^ou"t 
a boavd, -tV^cv-c v-cally 
»s^*t a ^a^c! 


分 gry s ^ame System Framewnrlf 
Feature List 

1. The framework supports different 
types of terrain. 

么 The framework supports different time 
periods, including fictiowal periods like 
sci-fi and fawtasy. 

多 • The framework supports multiple 

types of troops or units that are game- 
specific. 

4. The framework supports add-ow 
modules for additiowal campaigns or 
battle scenarios. 

5 The framework provides a board made 

叩 of square tiles, ahd each tile has a 
terrain type. 

6. The framework keeps up with whose 
turn it is. 

Z The framework coordinates basic 
ffiovemeytt 


Why? 







Cfb maybe QZ) 


thought tha-t 

troops wc^rc csschiial 

匕 , 3 如 c … 如 d 

u wc ho "t suve y/ha-t 
- W〆’ 

二吻 So two 
applied hcv-c. 
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e no . 

Questions 




I’m a little confused about what 


you mean by the "essence" of the 
system. Can you say more about that? 


The essence of a system is 
what it is at its most basic level. In other 


If I’m working on a new system, 
I probably won’t know how to do 
anything on my feature list. So won’t 
the 3rd Q of architecture about not 
knowing how to do something always 
apply? 


What you c/on Y want to do is see some 
things that look familiar—perhaps you’ve 
solved the same problem in another 
project—and start there. Start with the 
core pieces of the system, and the things 
that look like they might be particularly 
hard, and you’ll be on the road to 


words, if you stripped away all the bells 
and whistles, all the “neat” things that 
marketing threw in, and all the cool ideas 
you had, what would the system really be 
about? That’s the essence of a system. 


When you’re looking at a feature, 
ask yourself: “If this feature wasn't 
implemented, would the system still 
really be what it’s supposed to be?” If the 
answer is no, you’ve found yourself an 
“essence feature." In Gary’s system, we 
decided that the game wouldn’t really be 
a game without a board and some units, 
and there are some more examples in the 
Brain Power at the bottom of the page. 

If you don’t know what 
something means, isn’t that a sign that 
you’ve got bad requirements? 

No, but it is a sign that you might 
need to get some additional requirements, 
or at least some clarification. In the early 
stages, you can leave some details out 
to get a basic sense of a system. But at 
this stage, it’s time to fill in some of those 
details, and that’s what the second Q of 
architecture is all about. 


A ： 


No, not at all. For instance, even 


if you’ve never written code to decide 
whether a player typed in the letter “q” 
or the letter “x,” you know how to write a 
basic if/else statement, and it’s easy 


to grab keyboard input from a player. 

So a feature like getting keyboard input 


isn’t something you don’t know how to 
do, even if you’ve never written code 
specifically for that task before. It’s just a 
few new details, really. 


But if you had to write a multi-threaded 
chat server, and you’re new to threads 
and network programming, then that 
would be something that you don’t know 
how to do. Those are the things to look 
out for: particularly hard tasks that you’re 
unsure about how to handle. 


being 


Doesn’t this all end up just 
a judgment call, anyway? 


In a lot of cases, yes. But as 
long as you choose to start working on 


the things that seem the most important 
to the system, you’re going to get off to 
a good start. 


success. 


Tke essence 
ox a system 
is wnat tkat 
system is 
at its most 
basic level. 



贫办… _ 

What do you think the essence of each of these systems is: 

♦ A weather-monitoring station? 

♦ A home automation remote control? 

♦ A beat-controlling, music-mixing DJ application? 
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moving towards order 


WcVc got a lot less chaos wow... 


Using the three Qs of architecture, we’ve started to add some 
order to all that confusion we started out with: 



1. Tbc framework supports diffcrci 
types of terrain. 

2. The framework supports different time 
periods, including fictional periods like 
sci-fi and fantasy. 

$.the framework supports wultipU 
types of troops or units that m 
specific. 

4. The framework supports add-on 


modules for additional campaigns or 
battle scenarios. 

5. the framework provides a board made 

up of square tiles, af 

terrain type. 

6. The framework' 
turn it is. 

T The fraweworl vi^w 
wovewewt. 



峽 a 一加从 

stav-*tcd 




the core of all of 
classes with a well- 
^elopment 
irovide standard 


: SF will amplify the task of developing a tu 
° f GSF ^ deV 




\ 

f Move Units \ -一 


(^^epby GamT^) 

/ / 
The 




iheh wc 

^ ^ do 

^ ，S io do 


6 ^!：_ 一叩 _ Wh0se 

7 ^rHr rkcoord, ' Hat ^ 


asic 


Q 


Gary's System Framework 
KEY Features 


1. The board for the game 一 essence of the system 

2. &ame-specific units 一 essence, and what does this mean? 

3. Coordinating mov_ewt — what is it, and how do we do it? 


^avvovicd 七 doviv> 
to wst a ^ 

^caWcs to Uus or,. 



..but there's still plcwty left to do 


uniform, but there are still 
choices to be made... 


We’ve gotten Gary’s system down to three key features, but the 
big question remains: which one should you work on first? 


336 Chapter 7 
































































Acrgumewt 

Cubicle 加 


architecture 


Well, we obviously need to build 
the board first... I mean, ifs 
the essence of the system! 


Whatever! If you doiVt even know 
what ''game-specific units” means, 
that’s where to start. 


O 




Joe 


Jim: What in the world are you guys 
thinking? What good is it starting with 
anything that isn’t the essence of the 
system? 


Wrong! Start with the hardest thing- 
coordinating movement. 


Joe: That’s ridiculous. Even if that’s the essence of the system, you’ve got to figure out 
what game-specific units are. That could take weeks to write if it’s harder than we think! 

Frank: Maybe... but we know that coordinating movement will be tough, because we don’t have a clue 
how to do it! How can you possibly work on anything else when you know the movement deal is going to be 
difficult? 


Joe: But the game-specific units might be difficult, too! We just don’t know, and that’s my point. We’ve got to 
figure out the parts of the system we don’t know anything about, or they could be real trouble! 

Jim: You guys go on and write movement engines and deal with units. Me, I’m gonna write a board, 
because... well... something tells me Gary will want to see a board for his board game system. And I’m not about 
to leave the board for later... I’m taking it on first. 

Frank: You’re both nuts. While you’re putting off the hard tasks, I’m gonna make sure the things that I 
don’t have any real idea about are taken care of, right away. 


So who do you think is right? Po you agree with: 



(build the board) 



oe (build the game-specific units) 


CWk W W 心七丄 
to YiV^o 70U aycc ▲ 



rank (build the movement engine) 
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the problem is RISK 


Leave it to a bunch of 
boys to get into a big argument. 

I think they re ALL right... the problem 
isn't which feature to start with, 
the problem is RISK! 


i 1 " w °^ s ^ 

Joe, is 

air 9 ur ， ch-fes. 


The reason that these features are 
architecturally significant is that they 

all introduce RISK to your project. It 
doesn’t matter which one you start 
with — as long as you are working towards 
reducing the RISKS in succeeding. 

Take another look at our key features: 



Gary's frame System Framework 
KEY Features 


1. The board for the game—essence of the system* 

2. frame-specific units 一 essence, and what does this mean? 

3. Coordinating movement—what is it and how do we do it? 


SmtC ^ ^ OYX 
kwoYi —at 
tWs Jt 

be a ^ 

Jc Yiovk, 

a 

s 6 V^cd^ cs 

icadVmcs- 


‘㈣ 心 : —" 



If ihc 

^3iu\rcs o-p {he 
• h Pi 吻 ih c ^ : 

f SC}ri <>^ RISK 
ihe ^ 1 

woh'-t 
ihe sysl ， 


二 Cin. 


The point here is to REDUCE RISK, 
not to argue over which key feature 
you should start with first. You can 
start with ANY off these, as long as 
you’re focused on building what you’re 
supposed to be building. 
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architecture 




Well, I still think my risk is bigger 
than yours... 


Sharpen your pencil 


Find the risk in your own project. 


Think about the project you’re working on in your day job right now. 
Now write down the first thing you started working on when you 
started the project: 


Now think about the 3 Qs of architecture that we talked about back 
on page 332. If you applied those to your project, write down a few 
features that you think would be architecturally significant: 


If you look at those features closely, you’ll probably see that they all 
have a lot of RISK connected to them. They’re the things that could 
cause you lots of problems, or delay you getting your project done. 
In the blanks below, write down which of those features you think 
you should have worked on first, and why. What risks did it create? 
What risks could you have reduced by working on it first? 
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writing the board interface 


APcliiteeture Puzzle 




For Gary’s game system, let’s start out by working on the board module. Your 
job is to write a Board interface that game designers can then use and extend to 
build their own games. 


The problem: 

You need a Board base type that game designers can use to create 
new games. The board’s height and width are supplied by the 
game designers for their games. Additionally, the board can return 
the tile at a given position, add units to a tile, and return all the 
units at a given X-Y position. 


Your task: 

o Create a new class called Board. j ava. 

Add a constructor to Board that takes in a width and height, and creates 
a new board with that height and width. The constructor also needs to fill 
the board with square tiles, one at each X-Y position. 

❺ Write a method that will return the tile at a given position, given that tile’s 
X- and Y-position. 

Write methods to add units to a tile based on that tile’s X- and Y-position. 

❺ Write a method to return all the units on a tile, given the X- and Y-position 
of the tile. 


㈣ s ? 5 

boards _" 


These -the 
^-^ooirdiha-tcs. 





iWis ohc is si 

poWioh f 午 
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Cases Bx^osedi 

This week’s interview: 
Scenarios help reduce risk 


Head First: Hi there, Scenario, we appreciate you taking the time to talk with us today. 

Scenario ： I’m really happy to be here, especially in a chapter that isn’t just about use cases. 

HeadFirst: Well, yes, to tell the truth, I was rather surprised when I was told we’d be interviewing 
you. We’re really focusing on architecture here, and working on features that would reduce risk. 

Scenario ： Absolutely! Well, that sounds like a very good way to approach big problems. 

Head First: Yes, well... ahem... then why are you here? 

Scenario ： Oh! I’m sorry, I just assumed you knew. I’m here to help reduce risk, also. 

HeadFirst ： But I thought you were just a particular path through a use case. We haven’t even 
written any use cases yet! 

Scenario ： That’s no problem, I can still be a real help. I mean, look, let’s be honest, lots of 
developers just don’t ever really take the time to sit down and write out use cases. Good grief, it took 
you something like four pages in Chapter 6 to convince people to even use a use case diagram, and 
that’s much easier to draw than it is to write a use case! 

HeadFirst ： Well, that’s true... there is a lot of resistance to writing out use cases. But they’re really 
helpful, I thought they saved the day with Todd and Gina’s dog door. 

Scenario ： Oh, I agree! But in cases where developers just don’t have the time, or a use case is too 
formal for what’s needed, I can really give you a lot of the advantages of a use case, without all the 
paperwork. 

HeadFirst: Hmmm, that is appealing. So tell me how that works. 

Scenario ： Well, take that board you’ve been writing. Suppose you wanted to reduce the risks of 
Gary seeing it, and thinking of something important you forgot to add to it... 

HeacFirst: Ahh, yes, forgetting an important requirement is always a risk! 

Scenario ： Well, you could come up with a simple scenario for how the board would be used — 
that’s where I come in —— and then make sure the board works with everything in your scenario. 

HeadFirst ： But there’s no use case... what steps do we pick in the scenario we make up? 

Scenario ： It doesn’t have to be that formal. You might say, “The game designer creates a new 
board 8 squares wide by 10 squares high,” and “Player 1 kills Player 2’s troops at (4, 5) so the board 
removes Player 2’s troops from that tile.” 

HeadFirst ： Oh, so just little descriptions of how the board is used? 

Scenario ： You’ve got it! Then you run through each description, and make sure your board 
handles those cases. It’s not quite as thorough as a use case, but I really can help you make sure you 
don’t forget any big requirements. 

HeadFirst ： This is fantastic! We’ll be right back with more from Scenario. 
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figuring out a scenario 


ScenaRjo ScRangte 

Write a scenario for the Board interface you just coded. 

Reducing risk is the name of the game in this chapter. You’ve coded a Board 
interface based on a few requirements we gave you, but it’s your job to figure out if 
we forgot anything — before Gary sees your work and finds a mistake. 


is Hsk wcVc 

^y ,h 9 "t° reduce o\r 
Clinic usi h g a 


Your job is to take the fragments of a scenario from the bottom of this page, and put 
them into an order that makes sense on the bulletin board. The scenario should run 
through a realistic portion of a game. When you’re done, see if you left out anything 
on the Board interface, and if you did, add the missing functionality into your code. 
You may not need all the scenario fragments; good luck! 


iVc vc ^ 


d 

^ouflc 

*to 

you yt 

七 ed. 
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requests terrain at (2, 2) 


-for 七 he s^cr\av-io 

.一’- ^ 

l，s units lose the battle 


Game requests terrain 


■ Player Ts units los 
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Player 2s units win the battle 
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p^Use Cases Bx^osedi 


This week’s interview: 

Scenarios help reduce risk (cont.) 


HeadFirst： We’re back with Scenario, again. Scenario, we’re getting quite a few calls. Would you 
mind taking some of our listener’s questions? 

Scenario： Sure, rd be happy to. 

HeadFirst： Great. First, here’s one we’re getting a lot. This is from Impatient in Idaho: “So you’re 
saying I don’t need to write use cases, anymore, right? I can just use scenarios?” 

Scenario： Oh, thanks, Impatient, I actually get that question often. I firmly believe you should 
still write use cases whenever possible. I’m helpful for quick problems, and to find the most common 
requirements, but remember, I’m only one path through a use case. If there are lots of alternate 
paths, you might miss some important requirements if you used just a scenario for your requirements. 

HeadFirst： That’s right, we’ve actually had Happy Path and Alternate Path on our show before. 

Scenario： Well, they’re really just specialized versions of me, if you want the truth. We try not 
to talk much about our family relationships, we all wanted to make it in this world on our own. 

But we’re really all part of the Scenario family. And you really need all of us to be sure you’ve got 
a system completely right. But if you’re just getting started, and a use case seems like it might be 
premature, just using me is a good way to get started. 

HeadFirst： OK, here’s another question, from Nervous in Nebraska: “You said you would help me 
reduce risk, and I hate risk. Could you tell me exactly how you can help me avoid risk?” 

Scenario： Another good question. Remember, when you’re figuring out requirements, whether 
you’re using a use case, a use case diagram, or a scenario, you’re trying to make sure you are building 
just what the customer wants. Without good requirements, the risk is letting down or upsetting the 
customer by building the wrong thing. 

HeadFirst： So you’re reducing risk in the requirements phase? 

Scenario： A lot of the time, yes. That’s when you’re writing use cases, putting together a 
requirements list, and using lots of scenarios to chart out all the paths through a use case. 

HeadFirst： But you also help out in big project architecture, right? That’s why we’re interviewing 
you now? 

Scenario： Exactly. Sometimes, you don’t have a complete requirements list and a bunch of use 
cases, but you still need to get some basic work done to see how a system is going to work. That’s 
what we’ve been doing here: using a scenario to get the basics of a module or piece of code down, so 
you can get the basic building blocks of your application in place. 

HeadFirst： So you’re really a handy guy, aren’t you? 

Scenario： I’d like to think so. I help in gathering requirements, in being sure your use cases are 
complete, but also in architecture, helping you reduce risk and reduce the chaos and confusion 
around what a particular module or piece of code does. 
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reducing the risks to your success 


Scenarip §c_Bie SouitipH 

Write a scenario for the Board interface you just coded. 


Below is the scenario we came up with. Yours might be a bit different, but you 
should at least have the game designer creating the board, a battle occuring 
between Player 1 and Player 2, and units being both added to and removed from 



Gary's 备 awe System Framework 

Poard Scenario 


Game designer creates board with a 
height and widtii. 




Player 2 moves tank^pto (4, 5). 


1 moves artillery onto (4, 5). 


Player 1 battlgs Player 2. 


XhC 


TVis pavt 
stcr\av-io sc*U uf 
a battle beW ⑼ 
Playcv-1 ay\d 
Player 1. 


he s^Chdlrio 
^Ohtihucs ih the 

sc 乙 ohd 匕 olumh. 


Game requests terr^mi at (4, 5). 


Player 2 5 s units win the battle. 


^ u nMy i aW , 


loved from (4, 5) 


Player 1 moves subs to (2, 2). 


Game requests terrain at (2, 2). 






Player 1 ? s units lose the battle. ■ 

board 

M|^medesigner supplies height and width. _ 
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architecture 


there are ng 

Dumb Questions 




Where did those requirements for the 
Architecture Puzzle on page 340 come from? 


Now you’re telling me that use cases add 
risk? That can’t be right! 


A! From Gary, with some common sense added 
in. If you think about what Gary’s asked for, a game 
system framework, and then read back over the customer 
conversation in Chapter 6, you could probably come up 
with these requirements on your own. We did add a few 
specifics, like being able to add a unit to a specific tile, but 
that’s really just thinking through the problem. 

But why didn’t we write a use case to figure 
out the requirements? 

A! We could have. But remember, we’re not trying 
to complete the Board module, as much as get the basic 
pieces in place. That’s all we need to reduce the risk of 
completing this piece of Gary’s system. In fact, if we got 
into too much detail, we might actually add risk to the 
project, by working on details that really aren’t important 
at this stage of things. 


n. No, use cases don’t add risk when used at 
the right time. Right now, we've come up with some 
key features that could cause us headaches if we 
don’t figure them out. But that doesn’t mean we need 
to perfect the Board interface; we just need to get 
an understanding of how it works, so if there are any 
potential problem spots, we can catch them and avoid 
problems down the line. So at this point, the details 
you’d need to write a good use case are a bit of overkill. 

But once we’ve got the key features sketched out, and 
handled the major risks, well go back to each module 
and really start to add detail in. At that point, a use case 
is very helpful. 


So that’s why we used a scenario, right? To 
avoid getting into lots of unnecessary detail? 


Exactly. A scenario gives us lots of the 
advantages of a use case, without forcing us to get into 
lots of detail that we don’t need to worry about right now. 



Arcliitecture Puzzle (Revisited) - 

What’s missing in Board .java? 

Look closely at the scenario on the previous page. Did the 
requirements we used on page 340 cover everything in the 
completed scenario? If you think something is missing, write it 
in the blank below, and then add code to Board .java to handle 
the missing functionality. 
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how we wrote the board interface 


Architecture Puzzle Solution 

For Gary’s game system, let’s start out by working on the Board module. Below 
is the interface we wrote to handle what we thought the basic tasks of a board 
would be. See how your solution compares with ours. 


package headfirst. gsf . board; 今 


import java.util.ArrayList; 
import j ava.util.Iterator; 
import j ava.util.List; 


import headfirst. gsf . unit. Unit; ^ 


public class Board 


•modules wc deeded 
以 h Ch 岭 “ • 


rteve’s a dlass y/c II ortd^t 

• m a mmu-bc, smdc we wed 

\i {p ^misV^ uf Board. 


private int width, height; 
private List tiles; 


public Board(int width, int height) 
this.width = width; 
this.height = height; 
initialize (); 

} 



private void initialize () { 


W ^ S l3id 

h hc， ^ hi 




Boy\us Pcs ， 

Pv-'m6flc : Pull ou*t 
sc-buf Code m-to 
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iles = new ArrayList(width); 
for (int i=0; i<width; i++) { 

tiles.add(i, new ArrayList(height)); 
for (int j =0; j<height; j ++) { 

((ArrayList)tiles.get(i)) .add(j , new Tile ()) 

} 


V"CfV-CSCir\*tcdi *tv^c on 
board ds dr\ av-vay of av-v-ays, us'mj 
wid 从孙 d as dimeWcms. 
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Board.java 
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public Tile getTile(int x, int y) { 

return (Tile)((ArrayList)tiles.get(x-1)).get(y-1) 

} 

public void addUnit(Unit unit, int x, int y) { 

Tile tile = getTile(x, y); 
tile.addUnit(unit); 


public void removeUnit(Unit unit, int x, int y) { 
Tile tile = getTile(x, y); 
tile.removeUnit(unit); 

} 



public void removeUnits(int x, int y) 
Tile tile = getTile(x, y); 

-tile . removeUnits (); 

} 


丄 。— 

Oh 34 - 4 . T ,. 
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public List getUnits(int x, int y) 
return getTile(x, y).getUnits(); 

} 


there are no 

j umb Qu 


Here's a^otlicv flatc 

v/e delegate *to *t^c Tile dass. 

Sm 乙 e a tile s*to\rcs 七 he uir\i*b ov\ 
it iVs vcally *bi^c -tile s job -to 
於 die v-c-tv-icv'mj 七 hose ur\i*bs. 


.Dumb Questions. 

Doesn’t using an array of arrays limit you to a square 

board? 

A: No, although it does limit you to a board that uses (x, y) 
coordinates. For example, you can use (x, y) coordinates in a board 
made up of hexagon-shaped tiles, if you structure the hexagon tiles 
correctly. But for the most part, an array of arrays is more ideally 
suited to a square-tiled, rectangular board. 


So isn’t that limiting? Why not use a graph, or even a 
Coordinate class, so you’re not tied to (x, y) coordinates and a 
rectangular board? 

A: If you wanted maximum flexibility, that might be a good 
idea. For this situation, though, our requirements (back on page 
340) actually specified (x, y) coordinates. So we chose a solution 
that wasn’t quite as flexible, but certainly was simpler. Remember, 
at this stage, we’re trying to reduce risk, not increase it by going 
with a solution that is a lot more complex than we really need. 
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the tile and unit classes 


The Tile and Unit classes 

To actually make Board compile and work, we need to create a 
Tile and Unit class. Here’s how we wrote those classes: 


package headfirst. gsf . unit 

public class Unit { 

public Unit() { 

} 



class 
Unit { I 

Unit()4 


Unit.java 


M m 叫 e 叫 as absolutely simpl 

f poyible. allots or 

dcta.ls -to b c added but we 

n° h V ccd ^ dcia\\s io .ak c 

woirk Hght 


how. 




Tile »s m i\\t same patkay 

as *tV^c Boav-d class … 

v-cla*tcd- 

Tile has a lis*t of *thc u^i-ts 

o 灼 rt a 七 叫 givers -time- 


T\stst avc 


七 methods 
减 ?>o^A uses ^ 

ovoUdcd, so H 

l w<ua r 

adtess 七 ―. 


Keep the right focus 

You don’t need to worry about everything that Tile 
and Unit will eventually need to do. Your focus is 
on making Board and its key features work, not on 
completing Tile or Unit. That’s why we left Unit 
so bare, and added only a few methods to Tile. 


package headfirst. gsf . board; 

import java.util.LinkedList; 
import java.util.List; 

import headfirst. gsf . unit. Unit 

public class Tile { 

private List units; 

public Tile() { 

units 二 new LinkedList(); 


protected void addUnit(Unit unit) { 
units•add(unit); 

} 

protected void removeUnit(Unit unit) 
units.remove(unit); 




Tile.java 
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Focus on one 
ieature at a time 
to reduce risk in 
your project. 


Don’t get 

ctistracted 
witn features 


tkat won’t kelti 
reduce risk. 



e no . 

Questions 


If the Tile class handles adding and removing units, 
and you can get the tile at a coordinate from the Board using 
getTile(), why add those addUnit() and removeU_ methods to 
Board. Couldn’t you just call getTile(), and then use the Tile to do 
those things? 


A: You could take that approach, and let all the Unit-related 
operations be handled directly through the Tile object returned 
from getTile (). We decided to add the Unit-related methods 
to Board, and have Board be the entry point for game designers. 

In fact, you’ll see on the next page that we made Tile’s methods 
protected, so that only classes in the same package as Tile— like 
Board — could call addUnit () and removeUnit () directly. So 
we’ve really ensured that Board is the object used to work with tiles, 
units, and eventually terrain. 


I still think it would be easy to go ahead and add some 
more of the methods we know we’ll need to Unit and Tile. Why 
not spend a little time on those classes now? 

You’re not trying to code the entire game system framework at 
this point; you’re just trying to tackle a few key features, and reduce 
the major risks to your project. Spending time writing the Unit 
class, or fleshing out the Tile class, really isn’t going to help you 
reduce risk. Instead, do just enough to get the Board class working, 
because it’s the Board class that we decided was part of the 
essence of the system, and where we had a risk of failing if we didn’t 
get that piece in place. 

Once you’ve handled your key features, and reduced or eliminated 
the big risks to your project, then you’ll have plenty of time to work 
on other features, like the Unit class. At this stage, though, you’re 
trying to avoid spending time on anything that doesn’t help you reduce 
the risks to your project succeeding. 



ONLINE 


You can download these Board-related classes for Gary’s 
framework at http://www.headfirstlabs.com. Just look for Head 
First OOA&D, and find “Gary’s Game System - Board classes.” 
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architecture reduces chaos 


More order, less chaos 

Our architecture and key feature list has helped us 
get the basic Board in place, and make sure we’re 
capturing the essence of the system for the customer. 
Let’s look back at our key feature list: 


frarv's System Framework 

KEY Features 


^/fhe board for the garner-essence of the system 

2. &ame**spccific units 一 essence, and what does this mean? 

3 . CoordiKiatiKig movement 一 what is it and how do wc do it? 


iVc vc ^o*t *tV^c kas'it B<>av-d 
so Kay\dlcd 
Vq -feature cwou^ *to 

rv\OVC ov\ bo ano*t^cv*- 


WeVe got structure mow, too... 

Even better, we’ve got some basic classes in place, and 
we can start to think about our next key feature, and 
how it fits into this structure. 


h^vc 




呼 docs^i 
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architecture 


Which feature should we work ow wext? 


We've got a Unit class now, so why 
don’t we tackle 'game-specific units” next? 
Besides, we can also look at how Board and 

Unit interact. 


a 



sowc bad 
classes >wc 

cav\ look a 七 Koy/ 
classes as 

y/ell as kc^'m *to 
build or\ y/V^3*t vc 
alv-cady dio^c. 


Build on what you’ve already 
got done whenever possible. 

When you’ve got nothing but requirements 
and diagrams, you’ve just got to pick a 
place to start. But now that we do have 
some code and classes, it’s easiest to pick 
another key feature that relates to what 
we’ve already built. And remember our 
definition for architecture? 


Architecture is your 

design structure ， 

and highlights the 

most important 



parts of your app， and the 

C^^ationships^ 

between those parts. 


You really can’t talk about the relationships 
between parts if you don’t have two parts 
that have a relationship. We know Board 
and Unit are related, and that “game- 
specific units” are a key feature, so that’s 



the obvious thing to work on next. 
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know what you don’t know 

frame-specific units... 
what does that mcaw? 

The simplest way to understand a bit more about what 
“game-specific units” means is to talk to some of Gary’s 
customers, the game designers who will be using his 
framework. Let’s listen in on what they have to say: 


Strategy is the key for 
our games. We use an advanced 
combat system where each unit has an 
attack strength, defense strength, 
and experience modifier. 



I build sci-fi games, big huge space 
and planet battles. So I need to be able to 
have armies with lasers and create lots of 


spaceships. 


O 


Q 
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Our customers are all 
about air battles, so we dotVt even need 
troops. I just want to be able to create a 
bunch of different types of planes, with 
different speeds, weapons, and that 
kind of thing. 


No good war game is good 
without weapons... lots of different 
types of weapons. And our units can 
hold two each, so it gets really 
^ fun fast. 


o 



Our games are realistic 
and long-term... we even keep up 
with the ages and relationships 
between characters in our 

games. 




What does “game-specific units” mean? 


Now that you’ve heard from several of the game designers who want 
to use Gary’s game system framework, you should have a good idea of 
what our second key feature is all about. Write down in the blanks below 
your idea of what you need to do to support “game-specific units.” 


儀 ⑽ you’re dotie ， 

compare yo^ 

wttti ^ 

on lire next page. 
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exercise solutions 


§^0 

IE 站 RciS6 

、 • 

SpLjitlPHS 


iarpen your pencil 

tew answers What does “game-specific units” mean? 

Now that you’ve heard from several of the game designers who want to 
use Gary’s game system framework, you should have a good idea of what 
our second key feature is all about. Write down in the blanks below your 
idea of what you need to do to support “game-specific units, 

Each game based on the framework has different types of units, 

with different attributes awd capabilities. So wc need to be able 

to have properties fora unit that are different for each game, 

and support multiple data types for those properties. 


七 simula-tov-s 
use pistes, jd 
a^d v-otkets. 




Some av-w'y-v-cla-bcd 
^a^es —Wt have 

-tables a^d sold'«cv*s... 


心 ::㈣ 
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architecture 


Commonality revisited 


We’re starting to learn more about what “game-specific units” 
means, but we still need to figure out how to actually add support 
for this feature to our game system framework. Let’s start by taking 
a look at the different types of units the customers mentioned, and 
figure out what’s common between them. 


tteve av-c a 

pv-ofcv-tics, 
mcy\*t»oy\cd ov\ 

七 he last touplc 
Jc pays. 




lAfe -talked about tadk 

oh pay VS1 o-f C_tc “，々 w 
⑽ kas,t system 

^w,v-c^cr.ls. It also allies \x> smaller 

? voblcms, like -tKc umls. 


What is common among 
these different types 
of units? What basic 
things can we say that 
would apply to any 
game’s units? 
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what things are common? 


Design Puzzle 


It’s your job to figure out what’s common, and should be a part of the basic Unit 
class, and what varies, and belongs in the game-specific subclasses of Unit. Write 
any properties and methods that you think belong in Unit in the class diagram for 
that class below, and then add properties and methods that you think belong in the 
game-specific subclasses to those diagrams. 


rtcvcs ouv Ass ， 
or 

減 、 kp all 切广 

tWis tlass. 



: f ; 心二丄 一 . 
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严匕 seem 

apply io all iypes o-p Uhits? 
I^Vhidh ohly bclohg i h a 

spe 匕 i+i 匕 Whit subclass? - 






n i 

Rnori —— 


LH 

name = "Simon" 
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look a little deeper 

Solution # 1: It's all different! 


At first glance, you might have come up with a solution 
that looks something like this: 


really 

IdcWcv> -b^c a>Hcv-cy>t 
⑽ Vts. T^v all V^avc ? 代 ?# a 
W 七柹 c 广 opcrbcs a 代 diHcjrc^t 

«fov catW 七孓。⑽七 “ 
added \p W^*t base tlass. 



you m •吵七 V^avc \>u-t a weapem 

pv*ofCV"*tY 'Af smte it sounds 

like most 一 *b Will V^avc a y/ca?cm. 
Bu 七 y/Viat abou 七 uir\'i*ts V/»*bV) rrxort 
从扣 cme v/eapo ”？ TKcvc av-c still 
some pvoblcms y/*rtV) affv-oat^. 


%hks had a 
•Pew plropcv-tics 
sp^iVid -to \i, 
so those get 
added "to the 
Tahk class. 



:ou ruigh-t h^ve 
•9u\rcd out that 
^capoh tlass 
■ a 9°°d idea... 

: hat way, wc (iah 
s *toire ih+o\rry»a-tioh 

about wcapohs 3hd 

代 use those across 

^iaucs of the 

Whit dass. 
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architecture 


That was sort of dumb... why go 
through all this commonality stuff when 
there's nothing common between the 
different units? That seemed like a waste 

of time. 


O 


Commonality is about 
more than just the names 
of properties... you need to 
look a little bit deeper. 

It might seem like there’s not anything 
common across all the units used in 
different games, but let’s take a step back 
from focusing on the actual names of the 
properties for each unit. What’s really the 
same for each unit? 



Bach uhi-t has a di-Pfcvch-t 
type: tkirc amc soldier 
pUes, spaceships, tit. 



type = unitType 



propertyName = propertyValue 


V^as a 



…心南 ‘ C . 



So what is common is that a 
unit has a type and a set of 
properties, each of which is a 
simple name/value pair. 
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commonality creates flexibility 


Solution If s all the same! 

At first glance, you might have come up with a solution that 
looks something like this: 




丁 Wis wc vc w'Sdc IXhi 七 a 

lot 3 ⑼吖 匕 I 七 suffovts 

a “rb -type, ^v\A a Maf 

^dme/vdiue f\ropcvt»cs. 



Wcd^oy\s (cvcr\ multiple y/c3for>s pev 
unrt), S*bv"CK\5*b^) speed) C%fCV->Cir\tC, 

a^C) dy\d wtW” else a 
dicsi^cv w^Wt y\tt& sll be 
shored *m i\\t p\rofc^rtics Maf. 
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Thc\rc s k>o lohjcir a heed *fo^ 
lots o*f Uhi-t subdassd. we 

^ si ^ply use the Uhi 七 dlass 
with 3 di-Pfc\rCh-t type 5hd 

p<ropc\rty set 
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TWis ’ 

y-oy/ is y/V^a*b 
y/e’ve looked 
a*t so 孓 

unit -types. 


\^° sccr^ 

l，kc 3 loi bui 
lh ^ssivc wav 
3 ’ i 仏 ho + 

So toed. 


OK, this is ludicrous. Rrst, 
nothing was the same, and now everything 
is the same? How in the world is this 
helping me reduce risk or write better 

software? 


O 


Commonality analysis: the 
path to flexible software 

Wondering why we spent all that time on commonality 
analysis? Look back at the first solution on page 358, 
and then again at the second solution, on the left, and 
then fill out the table below to see what commonality 
has really bought us in terms of our design: 



Number ok 

uhi 七 iypes 

Number ok Uhrt 
classes — Solution 

Number ok Uhrt 
dlasscs — Solu 七 ioh 养 Z 




*5 



10 









loo 




Which solution do you think is better? 
Why? _ 
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commonality and flexibility 


Number or 
uhi 七 types 

Numbcv* ok Uhrt 
dlasscs — Solution 

Number ok ukrt 
classes — Solu 七 ioh 养 Z 


午 

1 

*5 

b 

1 

10 

II 

1 


li> 

1 


*51 

1 

loo 

/ 101 

1 



Solution #1, you al^s 
Kad a base tlass, a^d a 

subclass -fov tac\\ We identified what was 


=f luiio ^ -the single 
7'^ ^ ^PPo^ed all t y L 

u„ts W ith _ 一 b:If 



Unit 

type: String 
properties: Map 

setType(String) 
getType()： String 
setProperty(String, Object) 
getProperty(String): Object 


common, and put it in the Unit 
base class. The result was that 
game designers now only have 
to keep up with ONE unit class, 
instead of 25, 50, or 100! 


a single well— 
desired Uhit dlass, 
WC 匕 suPpoirt dhV 
humbev oi d\Ucvcv\i 
uhi-t types. 


D 



e no . 

Questions 


I can see how this would help me with my design, 
but what does any of this have to do with reducing risk? 


Good design 

will always 
rectuce risk. 


A! Good design always reduces risk. By figuring out 
how best to design the Unit class, we can get it right the 
first time... before we’re deep into working on the entire game 
system framework, and might have to make drastic changes to 
Unit that affect lots of other code. 

Not only have we figured out what “game-specific units” 
means, but we’ve defined the basic Unit class, and now 
other classes like Board can relate to it without worrying 
about its design drastically changing in the middle or near the 
end of the project’s development cycle. 
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Ahd still more order... 

We’ve figured out another key feature, 
reduced risk to our project even further, and 
only have one feature left to worry about. —» 




-- 

board for the game-essewceof the system 
V^ame-specific uyiits^esseyioe, and what does this mean? 
l C00rdmatiMg 瞻咖 t 一 what is it a W d how do we do it? 


Wait a second... we haven’t 
written any code for the Unit class. 
Don*t we need to do that before we 
go on to that last feature? 


O 


We’re focusing on doing just 
the things that reduce risk. 

Remember, the point of architecture is 
to reduce risk, and to create order. 

There are plenty of other things to work 
on in your application, but those are for 
after you’ve got a handle on how your 
application will be structured, and have 
the major risks reduced to the point where 
they are manageable. 


We were trying to get a handle on the 
Unit class, and what “game-specific units” 
meant; at this point, we’ve done that: 



TW»s dlass dia^v-am all 
at tW»s It 

awes vou stvudWc 
oJf t'ass, a^a 

does 


Unit 

type: String 
properties: Map 

setType(String) 
getType()： String 
setProperty(String, Object) 
getProperty(String): Object 
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e no . 

Questions 


When we worked on the Board, 
we did code the Board class, but now 
you say we shouldn’t code the Unit class. 
What gives? 




Is it really good to ask the 
customer and users of a system about 
what it should do? Couldn’t they lead us 
astray, or distract us? 


A) The question you need to be always 
asking at this stage of a project is, “Will this 
reduce the risk to my project succeeding?” 

If the answer is yes, you should go ahead; if 
it’s no, you probably can leave the task for a 
later stage of the project. 

In the case of the Board, we needed to 
have a basic understanding of what the 
game board does, so we went ahead and 
coded a basic implementation. But for Unit, 
a class diagram and understanding its basic 
functionality was all we really needed to do. 

In both cases, we were reducing risk to our 
project, rather than focusing on coding or not 
coding a certain class or package. 


It’s usually a good idea to ask the 
customer, because it is their system that 
you’re building. And really, the customer 
is only going to confuse you, or get you 
working on the wrong thing, if you’re unsure 
of what you’re supposed to be working on. 

As long as you go into a conversation clear 
on what your goals are, and you’re listening 
for something specific, you should be able 
to filter out anything that might confuse or 
distract you. 

I’m still not sure I would have ever 
come up with using a Map for storing 
properties in the Unit class on my own. 


But couldn’t we have just done a 
class diagram for Board, like we did for 
Unit, and stopped there? 


You probably could have just done 
a class diagram. It's really a judgment call, 
and as long as you feel you're focusing on 
reducing the risk in your project, it’s OK to 
stop with a class diagram, or take things a 
level or two deeper. 


That’s OK; that’s what tools like 
commonality and the three Qs of architecture 
are for. They help you get to solutions that 
you might not think of on your own, in a way 
that works on any type of project. 

In the case of the Unit class, the point isn’t 
that we used a Map to store properties. It's 
that we figured out that all units are basically 
just a unit type and a set of name/value 
pairs. Once we figured that out, the details 
about how we stored those name/value pairs 
were a piece of cake. 




So there’s really not a lot of code 
involved in OOA&D, is there? 


A! OOA&D is all about code—it’s 
about writing great software, every time. But 
the way you get to good code isn’t always 
by sitting down and writing it right away. 
Sometimes the best way to write great code 
is to hold off on writing code as long as you 
can. Plan, organize, architect, understand 
requirements, reduce risks... all these make 
the job of actually writing your code very 
simple. 


Sometimes 
the best 
way to write 


great code is 


to kolct of I 


on writing 
code as long 
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BE th^ 

All that’s left is to handle 
coordinating game noyenent. But 
what would you do next to figure 
tiiat out? Your job is to outline 
tire next few pa^es of IJead 
First OOA&D, and 
figure out how you’d 
t^ke care of lliis last 
l^ey feature. 





辦 nvt: 匕 he 吐 out 

wc did -fov* the 
1 办七 key 卜 Urc ihai 
wc wcirch'-t dca\r oh 
how -to gc-t sia^ied. 
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ask the customer 


What does it mcaw? 
Ask the customer. 



k ⑽:: 

jCouv paw a^A see V^o>m dose 


When you’re not sure what a feature really means, one of 
the best things you can do is ask the customer. We did this 
with the game-specific units, so let’s try the same thing for 
figuring out what coordinating movement means. 


This looks pv-ctiy s'tWigh'tfotw 狀 d … 
its a -Pai\rly Simply ddkulaiio^. 


Each unit has a movement property 
that says how many squares it can move, 
and the game checks the terrain to see if 
the move is legal. 


We hate games that aren’t 
realistic... like when airplanes can 
fly through buildings! Our games check 
all the surrounding tiles for other units, 
and then apply a wind factor to the 
planes speed property. 



H 



o 


o 




TW»s »s a k»*t 



TV^Ve 
u d at 7ct 

妆 ymc tV>at lets 
sWld^t be aWc t>- 



366 Chapter 7 























architecture 


▼ 


2. Commonality analysis 


USC ^ thv-CC basi^ 
7 C P S ( ah y^'^c youVc Uhsuv-e 
^bout what a Wc 

how you ,ced io —| ⑽ ,七 
that+catu\rc m y ouy . sy s + c 啪 


1 Ask tke customer 


▼ 


3 . Implementation plan 


Vo you kwow what "coordmatiwg 
movement" means? 

Listening to the customers should have given you a pretty 
good idea of what the third key feature of Gary’s game 
system framework is all about. Write what you think that 
feature really means in the blanks below: 


Now do some 
commonality analysis 

Next you need to try and figure out what’s common about 
the different movement scenarios that the customers on 
page 366 have been talking about. Are there some basic 
things that apply to all the different types of movement? If 
you think that there are, write those common things in the 
blanks below: 


So wow what would yoy do? 

If you have an understanding of what “coordinating 
movement” means, and you know what things are 
common across all games, you should have an idea about 
what you need to do to the game framework to make this 
feature work. Write your ideas down in this final set of 
blanks: 


wh QD t do CD s th CDfCD 3tu 「 CD m CD 3n -o 


How do I realize that feature 
in my system? 
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whose job is this? 

Is there awythmg common here? 

Here’s what we thought we needed to do based on what 
Gary’s customers were saying about movement: 


Uni'ls should be able bo move -fvom one 七 ile on 七 he 
boavd b> ancrbliev. Movemen-l is based on a dakula 七 ion ov 
spedi-Pid h> eadK and some 七 imes involves 

•bKe c\ame-spedi-fid pv-opevfces o-F a uni 七 . 


So what exactly is common among all the different 
possible movement scenarios? Remember what the 
customers said? 


O 


0 


We hate games that aren’t 
realistic... like when airplanes can 
fly through buildings! Our games check 
all the surrounding tiles for other units, 
and then apply a wind factor to the 
planes speed property. 



basca y i 



unit has a movement property 
that says how many squares it can move, 
and the game checks the terrain to see if 
the move is legal. 




Whafs common? 

What's variable? 

There's a check prior to a move 
to see if the move is legal. 

The algorithm to check a move's 

legality is different for every game. - - 

A uwifs properties are used to 
see how far the unit can move. 

The number and specific properties ^ - 

used are different for every game. 仏 〜^ c? ,K) 9 

Factors other thaw the unit 
^ affect movement. 

This is >whcv*c 七 hi 呼 like 

W\t\d speed dome *m*to flay. 

The factors that affect movement - 3 

are different for every game. 
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It’s "different for every game" 

Did you see what kept showing up in our chart? Every 
time we found some commonality, the variability 
column had the same words: u different for every game.” 




there are up 

Dumb Questions 


When you find more things that are 
different about a feature than things that 
are the same, there may not be a good, 
generic solution. --- 


itcl s y $ic ^ i-f 


Gary, weve thought it through, 
and we think we should let the game 
designers handle movement on their own. 
Anything we do in the framework would 
just make things a pain for 
them. 


OK, it seems like you’ve 
thought things through, so I*m OK 
with that. Game designers love 
having more control, anyway. 


How is this really that different 
from game-specific units? 


But there is some commonality, 
isn’t there? A movement algorithm, and a 
check to see if a move is legal, right? 


But then ask yourself: what does this really 
gain? Game designers are going to have 
to learn your interfaces, and if they don’t 


A: With units, we did find some 
commonality: every unit had a type, and 
then name/value properties. With movement, 
every single game looked like it would handle 
things differently. So it made sense to leave 
movement to the game designers, rather 
than come up with a solution that was so 
generic that it was essentially useless. 


A: You're right. So, in theory, you 
could write a Movement interface, 
with a method like move () that took 
in a MovementAlgorithm and a 
LegalMoveCheck, or something 
similar. And then each game designer could 
extend MovementAlgorithm and 
LegalMoveCheck. If you thought of 
something like this, nice work! You’re really 
ahead of the game. 


have a legality check, they might pass 
in null for the LegalMoveCheck 
parameter, and what would the interface for 
MovementAlgorithm look like, and... 
well, you’re probably adding complexity, 
rather than really removing it. 

Your job is to reduce risk and complexity, 
not increase it. We decided that it would 
be simpler to let game designers handle 
movement, and just change the position 
of units on the board (using methods on 
Board, which we did take care of for them). 
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great code or great software 


Customers 

cton’t 


pay you 
lor great 
code, tkey 
pay you 
lor great 
software. 


Great. So we’ve got a little 
sheet of paper with some checkmarks, 
a few classes that we know aren’t finished, 
and lots of UML diagrams. And I*m 
supposed to believe this is how you 
write great software? 


Absolutely! Remember ， 
great software is more 
than just great code . 

Great code is well-designed, and 
generally functions like it’s supposed 
to. But great software not only is well- 
designed, it comes in on time and does 
what the customer really wants it to do. 

That’s what architecture is about: 
reducing the risks of you delivering 
your software late, or having it not work 
like the customer wants it to. Our key 
feature list, class diagrams, and those 
partially done classes all help make sure 
we’re not just developing great code, but 
that we’re developing great software. 
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architecture 


Reducing risk helps you 
write great software 

With all three key features figured out, we’ve 
got a handle on the major risks to our project 
succeeding. Look at how each step we’ve taken 
in this chapter has reduced the risks to our 
project: 


frarv's System Framework 
KEY Features 


he board for the game — essence of the system 
'^^ame-specific units — essence, and what does this mean? 
^Coordinating movement—what is it and how do we do it? 


Wcrts v/c staged, t 

\l^ ^ *to 

build, wt y^oi else. 


I/Ve -Piguvcd out the b^sid 
classes -fo\r the BoS\rd, but 
\us-t Chough todt -to 
lowc\r the Hsk o\ gcUihg the 
bo 扣 d w\rohg -fo\r the Uz{x>f^tY. 


Nc 此 ^ ^»^cd out 

讪 at - 和，松 ■ 
“rb” wca^t, a^d 
? la^cd V^ovi Yic d V^a^dlc 

从 at 心 a*Ure a 

tlass d'»a^aw. 


Finally, wc used 
^ommohdl'rky -fco vcaliz^ 
"that hdhdlih^ rnovcrwCht 
was -Pov- the 
dcsi^hcv- -fco wovvy 
about- clhothcv 
risk -takch dav-c of. 


V\fe (WUavc a lo 七十 。严 卜七 

从 do have a 

to^i v/e 6a ; delwev o ； t-e, 
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r- BULLET POINTS 


■ Architecture helps you turn all your diagrams, plans, 
and feature lists into a well-ordered application. 

■ The features in your system that are most important to 
the project are architecturally significant. 

■ Focus on features that are the essence of your system, 
that you’re unsure about the meaning of, or unclear 
about how to implement first. 

■ Everything you do in the architectural stages of a 
project should reduce the risks of your project failing. 

■ If you don't need all the detail of a use case, writing a 
scenario detailing how your software could be used can 
help you gather requirements quickly. 

■ When you're not sure what a feature is, you should ask 
the customer, and then try and generalize the answers 
you get into a good understanding of the feature. 

■ Use commonality analysis to build software solutions 
that are flexible. 

■ Customers are a lot more interested in software that 
does what they want, and comes in on time, than they 
are in code that you think is really cool. 







architecture 



OOA&D Cross 

The march of the crossword continues. Have you 
gotten every answer so far? Here’s another set of 
clues to help you store all this architectural info 
in your brain for good. 



Across 

fii. on the thing 这 in your system 十 hat 

whitccturally_f rrst. 

9. These are the fcal^jres that you sh^uJd 
f oclj 5 on 

11. Use coses add ri^k when used At this tFmfi, 

12 Th^. pAKp.nr.p. fif n k whnt 十 hp. 

at iti 巾 ofi 十 _. 

13. FuLLiimy un mens 1 hun une; fcxjSurne ui u 
trme does ThrS tn The your project. 

15. U^e this type of annoys is whe/i you're rwt 
Sure haiv to * j mp(fimerit q conflicting Set of 
features. 

1L. rdhitcchur* IWghNgh 十 3 fhtifi po.rti tif your 
appSicat/an. £Z words) 

17. Commomlrty analysis one path to thfs 
tvpe of Software, 


Down 

1. Always 或 tart a project by focu^^ an 會 hi 这 . 

2. Tine Second Q of arch i feciturc ^3 abcut the 
_of a feature. 

3 . TJie first Q af archriecture is about thi^. 

4. you focus on kty features to rfidyce fhrs in 

ynuF prf>jp.f!t 

6. Tlnssa are a way to ba£«c. requirGmsRte 
wi 1 huu I I he d^huFK uf u u^ie 

7. This is not the same as great code. 

0. Vou usual』/ trade off ffexibiFity for this in 
your project's design. 

10. yeu ui e ardhi 十 ee 十 ure to 十 ujrn >a Ricsf into 
ih^s kind of a.ppJJcation. 

14. You write 言 his Type of software the same 
way, whether it's a big System c-r a small one. 
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puzzle solutions 


Sharpen your pencil 


awswers 


What’s missing in Board .java? 


Look closely at the scenario on the last page. Did the requirements 
we used on page 340 cover everything in the completed scenario? 
If you think something is missing, write it in the blank below, and 
then add code to Board .java to handle the missing functionality. 

The scenario talks about removing units, but there is no 

requirement to remove units on page 340. 



add ^ a vcmovcMhitO 
ahd ^ovcWhitsO method 

艺 t>oavd java h> hahdle 

this V-c^uiirc^Ch-t. 
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8 design principles 


Originality is Overrated 





s*> 


Baby, somebody better call 
heaven, 'cause they're missing an 
h angel tonight! 


I must have heard that line a 
thousand times, but it works 
on me every time! 


Imitation is the sincerestform of not being stupid. 

There’s nothing as satisfying as coming up with a completely new and original 
solution to a problem that’s been troubling you for days — until you find out 
someone else solved the same problem, long before you did, and did an 
even better job than you did! In this chapter, we’re going to look at some 
design principles that people have come up with over the years, and how 
they can make you a better programmer. Lay aside your thoughts of “doing it 
your way ”； this chapter is about doing it the smarter, faster way. 
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whafs a design principle? 

Pesign principle roundup 

So far, we’ve really been concentrating on all the things that 
you do before you start coding your application. Gathering 
requirements, analysis, writing out feature lists, and drawing use 
case diagrams. Of course, at some point you actually are going 
to have to write some code. And that’s where design principles 
really come into play. 


/ "'A design principle is a basic tool or 

technique that can be applied to designing 
\ or writing code to make that code more 

'Jr maintainable, flexible, or extensible. 


You’ve already seen a few design principles in earlier chapters: 


00 Pvmdiples 

Encapsulate y/hat vavics. 

Code to ^y\ *m*bcv-fa^c {\\av\ *to 

dass m youv application should 
have or\ly oy\t veasor^ *to 

Classes ave about bchaviov a^d 


Using proven 
00 design 
principles 
results in more 


maintainalile, 

flexible , and 
extensible 

software. 


In this chapter, we’re going to look at several more key design 
principles, and how each one can improve the design and 
implementation of your code. We’ll even see that sometimes 
you’ll have to choose between two design principles... but we’re 
getting ahead of ourselves. Let’s begin by looking at the first of 
our design principles. 
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design principles 


Principle *1: 

The Open-Closed Principle (OCP) 

Our first design principle is the OCP, or the Open-Closed 
principle. The OCP is all about allowing change, but doing 
it without requiring you to modify existing code. Here’s 
how we usually define the OCP: 




Closed for wodication … 

Suppose you have a class with a particular behavior, and you’ve 
got that behavior coded up just the way you want it. Make sure 
that nobody can change your class’s code, and you’ve made 
that particular piece of behavior closed for modification. In 
other words, nobody can change the behavior, because you’ve 
locked it up in a class that you’re sure won’t change. 

••but open for extension 


>u dose dlasscs by Y\oi 

allow.” *to *touA 
youv y/ov-km^ todt- 


CLOSED 


But then suppose someone else comes along, and they just have 
to change that behavior. You really don’t want them messing 
with your perfect code, which works well in almost every 
situation... but you also want to make it possible for them to use 
your code, and extend it. So you let them subclass your class, 
and then they can override your method to work like they want 
it to. So even though they didn’t mess with your working code, 
you still left your class open for extension. 




Y 0[a ^losses by 

"them -fco be 

subclassed at\d extended. 
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ocp in action 


Remember working on Rick's 
Striwgcd Iwstrumcwts? 

You probably didn’t realize it, but we were using the Open- 
Closed Principle when we wrote those Instrument Spec 
classes for Rick’s Stringed Instruments, back in Chapter 5: 


InstrumentSpec 


model: String 


getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 


base 6lass. It AtUts a -aU 广 

V>as a s ? e - 



GuitarSpec 


numStrings: int 


getNumStrings(): int 
matches(GuitarSpec): boolean 


MandolinSpec 


getStyle(): Style 

matches(MandolinSpec): boolean 


ms*brumeirrb - sfede 

subdasses c%*bcr\d *bV^c ma*t^^csO 
mctW .. use base version 
-fyom |r\S*b\rumCir\*tSfC£>) bu*b 3dd 
some maUVi'rnj detail spctiVit 

•to wovk 


w 



The pav*ts of 

^■UhesO iha-fe 
subclasses avc 

^ ih e 
base dlass. 


InstrumentSpec is elosect for tnoctilication ； tke 
matckesO metkoct is ctefinect in tke t>ase class 
ana doesn’t ckan^e. 

But it’s open for extension, because alt oi tke 
subclasses can ckantfe tke tekavior oi matckesO. 

—^ - o ^ 
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design principles 


The OCR step-by-step 

Let’s take what we did back in Chapter 5, and look at in terms 
of the OGP, one step at a time. 

o We coded matches() in InstrumentSpec. 
java, and closed it for modification. 

This version of matches () works just fine, and we don’t 
want anyone messing with it. In other words, once we’re 
done coding InstrumentSpec and this version of 
matches (), they shouldn’t change. 



InstrumentSpec 

model: String 

getBuilder(): Builder 
getModel(): String 
getType(): Type 
getBackWood(): Wood 
getTopWood(): Wood 
matches(lnstrumentSpec): boolean 


else ■bo'AtWv ^七 


❾ But we needed to modify matches() to work 
with instrument-specific spec classes. 

Even though matches () works great for other 
InstrumentSpec objects, it doesn’t quite do what it should 
for guitars and mandolins. So even though matches () 
is closed for modification, we need a way to extend and 
change it... otherwise, InstrumentSpec isn’t very flexible, 
which is a big problem. 


o So we extended InstrumentSpec, and 

overrode matches() to change its behavior. 

We don’t want to change the code in InstrumentSpec, but 
we can extend it, with Guitar Spec and MandolinSpec, 
and then override matches () in each of those classes to 
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more than inheritance 



Gee, inheritance is powerful. Really, 
this is supposed to be some sort of great 
design principle? Come on. 




The OCP is about flexbilitv, and 
goes beyond just inheritance. 

It’s certainly true that inheritance is a simple 
example of the open-closed principle, but 
there’s a lot more to it than just subclassing and 
overriding a method. Anytime you write working 
code, you want to do your best to make sure that 
code stays working... and that means not letting 
other people change that code. 

But there are going to be times when that code 
still needs to be changed, maybe for just one or 
two particular situations. Rather than just diving 
into your code and making a bunch of changes, 
the OCP lets you extend your working code, 
without changing that code. 

There are lots of different ways to accomplish 
this, and while inheritance is often the easiest 
to implement, it’s certainly not the only option. 
In fact, we’ll talk about another great way to 
achieve this later in the chapter, when we talk 
about composition. 
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design principles 



arpen your pencil 

Find the OCP in your own project. 


Think about the project you’re currently working on. Can you find any places where 
you’ve used the OCP already? If so, write how you used the OCP in the blanks below: 


Now think about a place in your project where you should be using the Open-Closed 
Principle, but you aren’t yet. Write down in the blanks below what you think you need 
to do to put the OCP into place in your current project: 


D 


there ar 

umb i 


e no • 

Questions 


What’s the big deal about 
modifying code in a base class, or a class 
that you’ve already written? 


Isn’t the OCP just another form of 
encapsulation? 


Once you have a class that works, 
and is being used, you really don’t want to 
make changes to it unless you have to. But 
remember, CHANGE is the great constant 
in software development. With the OCP, we 
allow for change through extension, rather 
than having to go back and modify your 
existing code. Subclasses can add and 
extend the base class’s behavior, without 
messing around with code that you already 
know is working and making the customer 
happy. 


A 〔 It’s really a combination of 
encapsulation and abstraction. You’re finding 
the behavior that stays the same, and 
abstracting that behavior away into a base 
class, and then locking that code up from 
modification. But then when you need new 
or different behavior, your subclasses handle 
the changes by extending the base class. 
That’s where encapsulation comes in: you’re 
encapsulating what varies (behavior in the 
subclasses) away from what stays the same 
(the common behavior in the base class). 




So the only way to use the OCP is 
by extending another class? 


A: No, anytime your code is closed for 
modification but open for extension, you’re 
using the OCP. So for example, if you had 
several private methods in a class, those 
are closed for modification—no other code 
can mess with them. But then you could 
add several public methods that invoked 
those private methods in different ways. 
You’re extending the behavior of the private 
methods, without changing them. That’s 
another example of the OCP in action. 
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don’t repeat yourself 


Principle 

The Pow't Repeat Yourself Principle (PRY) 

Next up is the Don’t Repeat Yourself principle, or DRY for short. This is 
another principle that looks pretty simple, but turns out to be critical in 
writing code that’s easy to maintain and reuse. 


1MY 


Don't Repeat Yourself 

Avoid duplicate code by abstracting out 
things that are common and placing 
those things in a single location. 


A prime place to apply WL 


You’ve seen the DRY principle in action, even if you didn’t realize it. 
We used DRY back in Chapter 2, when Todd and Gina wanted us to 
close the dog door automatically after it had been opened. 



public void pressButton() { 

System.out.printIn( 

''Pressing the remote control 
if (door.isOpen ()) { 

door.close (); 

} else { 

door.open (); 


final Timer timer = new Timer(); 
timer.schedule(new TimerTask() { 

public void run() { 

door.close(); 
timer.cancel(); 


k opened? ° Uc ^ 


Remote {I 
press-J, 

Button ()1 

—J 

emote.java 


}, 5000); 




public void recognize(String bark) { 

System, out .printIn BarkRecognizer : 

''Heard a '" + bark + 
door.open(); 


PRV，a BAP ^ 


final Timer timer = new Timer 。； 
timer.schedule(new TimerTask() { 

public void run() { 

door.close(); 
timer.cancel(); 

} , } 5000 ); 


class I 
BarkRec¬ 
ognizer 
{ 

update! 


BarkRecognizer.java 
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design principles 


1. Let's abstract out the common code. 

Using DRY, we first need to take the code that’s common 
between Remote and BarkRecognizer, and put it in a 
single place. We figured out back in Chapter 2 the best place 
for it was in the DogDoor class: 


Usm^ PRV ， v/C 
ou*t all do< ^ c 

and 以七沌 … ON 仨 
? iadc ： PooyPoov 
^IdSS. So y \0 move 
(Jufl'i6a*tc 

moV"C m3»^*bcy\3v\6C 


public class DogDoor { 
public void open() { 

System, out .print In (''The dog door opens .’’）； 
open = true; 


final Timer timer = new Timer () 
timer.schedule(new TimerTask() 
public void run() { 

close(); 
timer.cancel(); 

} 

}, 5000); 




DogDoor.java 


2. Now remove the code from other locations... 

3. ...and reference the code from Step 

The next two steps happen at the same time. Remove all the code 
that you put in a single place in Step # 1, and then reference the code 
you abstracted out explicitly if you need to: 


tW»s 6 ode... ^sa« 
m po^Poov s o—) 
method y>o^- 


public void recognize(String bark) { 
System, out .println ('' BarkRecognizer 
''Heard a 、" + bark + r, ); 

door.open(); ___ 

f ingri Timer timer ■ new Timor (); 

.aGhcdulc (new TimcrTaok( ) — ( 

-publie void run () — {■ 

d.UUl . Ll"Ooti (); 

timer.oancol {]; 

} 二 000); 



M dot\i have io 
^pliditly dsll h c 

toAt ^ ^hr^citd 
out * 士奶 Shelled 
卜 dy by ou … || 
doov.opchO. 


BarkRecognizer.java 
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using DRY the right way 


PRY is really about ONE 
requirement iw ONE place 


Abstracting out duplicate code is a good start to using DRY, 
but there’s more to it than just that. When you’re trying to 
avoid duplicate code, you’re really trying to make sure that 
you only implement each feature and requirement in your 
application one single time. 


In the dog door we just looked at, the feature we were trying 
to implement was automatically closing the door. 


Todd ami Nina's Poq Poor ： version 2.0 

Requirements List 

1. The dog door opening must be at least 1 T tall. 

2. A button oki the remote cowtrol opens the dog door 

if the door is closed, and closes the dog door if the 
iAoiUs-opm - - 

3. Once the dog door has opened, it should ciose" 
automatically if the door isn't already closed. 


^Ws ihe sihjle 
^C^uilrcrhCh-t wcVc 
-ro^usihg oh here. 


Originally, though, we implemented that single feature in two 
places: Remote. java and BarkRecognizer. java. 


13 

Remote.java 



BOTH -tV^csc 

Kavc todc 七 h 七 

closes 七 he do^ doov-. 


By using DRY, we removed the duplicate code. But 


more importantly, we moved the implementation of this 
requirement, automatically closing the door, into one place, 
instead of two places: 
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DogDoor.java 


Wow 七一 is just OHB yUc 
wc au^tomatiully dose -the 
o(W), i h pogpoo^*. 






















design principles 


ttere are no • 

Dumb Questions 




So DRY /sn^ about duplicate code, and 
avoiding copy-and-paste? 

A: DRY is about avoiding duplicate code, but it's 
also about doing it in a way that won’t create more 
problems down the line. Rather than just tossing code 
that appears more than once into a single class, you 
need to make sure each piece of information and 
behavior in your system has a single, clear place where 
it exists. That way, your system always knows exactly 
where to go when it needs that information or behavior. 

If DRY is related to our features and 
requirements, then shouldn’t we apply it to 
gathering those features and requirements as well 
as writing our code? 

Absolutely, and that’s a great idea! Whether 
you’re writing requirements, developing use cases, or 
coding, you want to be sure that you don’t duplicate 
things in your system. A requirement should be 
implemented one time, use cases shouldn’t have 
overlap, and your code shouldn’t repeat itself. DRY is 
about a lot more than just code. 

And this is all to avoid maintenance 
problems later, right? 

Right. But it’s more than just avoiding a need to 
update code in more than one place. Remember, DRY 
is about having a single source for a particular piece 
of information or behavior. But that single source has 
to make sense! You wouldn’t want the bark recognizer 
to be the single source for closing the dog door, would 
you? Do you think the dog door should be asking the 
recognizer to close itself? 

So DRY is not just removing duplication, it’s also about 
making good decisions about how to break up your 
system’s functionality. 


mi\ T 



DRY is about 

kavingf eacli piece 
ol information and 
behavior in your 
system in a single, 
sensible place. 
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applying DRY to requirements 


-Design Puzzle - 

DRY is about a lot more than just finding duplicate code in your system. It also 
applies to your features and requirements. It’s time to put DRY into action on 
your own now, and to do it in more than just code. 



The problem: 

Todd and Gina have come up with yet more features for their dog 
door. It’s your job to make sure the feature list we’ve assembled 
doesn’t have any duplication issues, and that each feature is handled 
once and only once in the system you’re designing for them. 


Your task: 

o Read through the requirements and features list on the right. We’ve bolded 
the requirements and features that have been added since you last worked 
on the dog door. 

❾ Look through the new features and requirements, and see if you see any 
possible duplication in the new things you’d need to build. 

Annotate the requirements and features list indicating what you think has 
been duplicated. 

o Rewrite the duplicate requirements at the bottom of the list so that there is 
no more duplication. 

❺ Write a new definition for the DRY principle in the space below, and make 
sure you talk about more than just duplicate code. 


心 ：㈣ 
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design principles 


TV^sc a 代 , 

aWcad” ⑽ ... 〆 


...a 灼 d -tiicsc av-c *tiic 
灼 cv/ -fca*tuv-cs By\A 
VC^UiVCmCn'ts- 


' 


Todd and Nina's l?oq Poor version 3.0 

Requirements and Features List 

I. The dog door opening must be at least 1 T tall. 

么 A button ow the remote control opens the dog door 
if the door is closed, and closes the dog door if the 
door is open. 

炙 Once the dog door has opened, it should close 
automatically if the door isn't already closed. 

4. A bark recognizer must be able to tell when a dog 
is barking. 

5. The bark recognizer must open the dog door when 
it hears barking. 

6. The dog door should alert the owner when 
something inside the house gets too close for the 
door to open without knocking if over: 

Z The dog door will open during certain hours of the 
day. 

8. The dog door can be integrated into the house's 
overall alarm system to ensure the alarm doesn't 
go off when the dog door opens and closes. 

9. The dog door should make a noise if the door 
cannot open because of a blockage outside. 

10. The dog door will track how many times the dog 
enters and leaves the inside of the house. 

II. Whew the dog door closes, the household alarm 
system re-arms if it was active before the door 
opened. 


吖 dated r — 了喊 
iout du ? V^aW ， 

V>otW 

oJf tV>c V»st- 


► Solutions on the next pa 贫 e. 
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-Design Puzzle Solutions —— 

DRY is about a lot more than just finding duplicate code in your system. It also 
applies to your features and requirements. Your job was to put DRY into action 
on your own, in the context of requirements rather than just code. 


The problem: 

Todd and Gina have come up with yet more features for their dog 
door. It’s your job to make sure the feature list we’ve assembled 
doesn’t have any duplication issues, and that each feature is handled 
once and only once in the system you’re designing for them. 

Your task: 

o Read through the requirements and features list on the right. We’ve bolded 
the requirements and features that have been added since you last worked 
on the dog door. 

Look through the new features and requirements, and see if you see any 
possible duplication in the new things you’d need to build. 

❺ Annotate the requirements and features list indicating what you think has 
been duplicated. 

Rewrite the duplicate requirements at the bottom of the list so that there is 
no more duplication. 

Write a new definition for the DRY principle in the space below, and make 
sure you talk about more than just duplicate code. 


St 


oum 


1M1 

^^epe^e/f J 

\ / PRY is about having each piece of 

/ information and behavior m vour 


/ system iw a sinak sensible place. 
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广 

Wes or. tV.c ^de, 

从 co 办芍， $ 七 

V>as \6 WW't'f 
tV>c saw. 


f(c<\u'»v-cwc^*b 一 

a^a ^ mc, 

a^d staved W sawe. 


Wcv*c s how we 
匕 ombmed av\d v-c- 
wvo-tc #^> a h d 


Todd and Nina's l?og Poor version 炙 0 

Requirements and Features List 

1. The dog door opening must be at least 1 T tall. 

2. A button on the remote control opens the dog door 
if the door is closed, and closes the dog door if the 
door is open. 

S. Once the dog door has opened, it should close 
automatically if the door isn't already closed. 

4. A bark recognizer must be able to tell whew a dog 
is barking. 

5. The bark recognizer must open the dog door when 
it hears barking. 

6rfhc dog door should alert the owner when 
something iMoidc the house geta too dose for the 
dtmrto open without knocking it over 

7. The dog door will open during certain hours of the 
day. 

8. The dog door can be integrated into the house's ^ 
overall alarm system to ensure the alarm doesn't 
go off when the dog door opens ami closes. 

9rfhe dog door should make a 刖 i 邶 if 1 松 duur 

oamiot opcii bcoauge-ofa- blockagt oirhid er 

10. The dog door will track how many times the dog 
enters and leaves the inside of the house. 

11. Whew the dog door closes, the household alarm ^ 
system rc-arms if it was active before the door 
opened. 


The door alerts the owner if there is an obstacle 
inside or outside of the house that stops the door 
from operating. 

When the door opens, the house alarm system will 
disarm, and when the door closes, the alarm 
system will re-arm (if the alarm system is turned 

Oh). 


did io ih e 

list. 



3r\d ^r \I bo 七 
relate *to 七 house 

really dupli^a-tcs 
Jt ： 七 he same basi 匕 

切 ，^ 00 ' 


rteve S OVAV ^ 

S«a ， d#ll- 
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the single responsibility principle 


Principle *5: 

The Single Responsibility Principle (SRP) 

The SRP is all about responsibility, and which objects in your 
system do what. You want each object that you design to have just 
one responsibility to focus on — and when something about that 
responsibility changes, you’ll know exactly where to look to make 
those changes in your code. 




C 


Single Responsibility Principle 

Every object in your system should 
have a single responsibility, and all the 
object’s services should be focused on 
carrying out that single responsibility. 



You’ve impleinentect tke 
Single Responsibility 
Principle correctly wlien 
eaclt ol your objects lias 
only one reason to cltang^ 

■ J 一 - o 一 



緩 
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SRP sounded a lot like DRY to 


me. Aren’t both about a class doing 
the one thing it，s supposed to do? 


And using SRP will help my 
classes stay smaller, since they’re 
only doing one thing, right? 


A: They are related, and often 
appear together. DRY is about putting a 
piece of functionality in a single place, 
such as a class; SRP is about making 
sure that a class does only one thing, 
and that it does it well. 

In good applications, one class does 
one thing, and does it well, and no other 
classes share that behavior. 


Isn’t having each class do 
only one thing kind of limiting? 

A: It’s not, when you realize that 
the one thing a class does can be 
a pretty big thing. For example, the 
Board class in Gary’s Games does a 
lot of different small tasks, but they’re 
all related to a single big thing: handling 
the board in a game. It does that one 
thing, and that’s all the Board class 
does, so it’s a great example of using 
the SRP. 


A: Actually, the SRP will often 
make your classes bigger. Since you’re 
not spreading out functionality over 
a lot of classes—which is what many 
programmers not familiar with the SRP 
will do—you're often putting more things 
into a class. 

But using the SRP will usually result in 
less classes, and that generally makes 
your overall application a lot simpler to 
manage and maintain. 




This sounds a lot like 


cohesion, are they the same thing? 


A: Cohesion is actually just another 
name for the SRP. If you’re writing 
highly cohesive software, then that 
means that you’re correctly applying 
the SRP. 
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srp analysis 


Spotting multiple responsibilities 


Most of the time, you can spot classes that aren’t using the 
SRP with a simple test: 

o On a sheet of paper, write down a bunch of lines like this: The [blank] 

[blanks] itself. You should have a line like this for every method in the class 
you’re testing for the SRP. 

❺ In the first blank of each line, write down the class name; in the second 
blank, write down one of the methods in the class. Do this for each 
method in the class. 

o Read each line out loud (you may have to add a letter or word to get it to 
read normally). Does what you just said make any sense? Does your class 
really have the responsibility that the method indicates it does? 

If what you’ve just said doesn’t make sense ， 
then you’re probably violating the SRP with 
that method. The method might belong on a 
different class... think about moving it. 


什 s whai Vou^ 

? ，yS ' S 

s ^ould look like. 


SRP Analysis for 

叫 d ⑽”如 

The 

tath method 
•(Vo 州 -the dass ih -this 
〆 blahk ； ov\t pev- lihC. 

itself. 

The 

itself. 

The 

itself. 
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arpen your pencil 

Apply the SRP to the Automobile class. 


Do an SRP analysis on the Automobile class shown below. Fill out the sheet with 
the class name methods in Automobile, like we’ve described on the last page. 
Then, decide if you think it makes sense for the Automobile class to have each 
method, and check the right box. 



looked 
tWis dlass 
CATASTROPHE 



十乂 wc you dah peck b^k 

气 〜 d —Uw, U 

Wc 代 y ou ho £ ^ T 

o h youir owh a h d 

o.ly look b^k ^ what w C did i, 

^ you 如 k 


SRP Analysis for 

Automobile 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 

The 

itself. 



Follows Violates 
SRP SRP 





^ you Ytad doesn't 

力 L S f^ -the method 

° h Imc is probably 

violatih 3 the SRp. 
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single responsibility 


Sharpen your pencil 

^ ftWSWCrS Apply the SRP to the Automobile class. 

Your job was to do an SRP analysis on the Automobile class shown below. You 
should have filled out the sheet with the class name methods in Automobile, and 
decided if you think it makes sense for the Automobile class to have each method. 


I 七 makes 
七七七 he 

au'tow'okilc 

v-csfoy\s*iblc {。矿 

s*tarbm 少 a”d 
s*bo^iv>^- T^ 3 *t s 

七 he aurtowoWe. 


du^oirMobilc is 
V-cspohsiblc 

its ov/h tiires, 
wdshih 0 

饮 ^hc^kihg iis 
owh oil. 



SRP Analysis for AuWobile 


Au*bomobilc 

s*ta\r 七 [s] 

Autonaobilc 

s*topCs3 

/\u*bonr\obilc 

dhahOicsTircs 

Automobile 

drivcCs] 

Automobile 

y/ashCcs3 

/\u*boinr\obilc 

t\\ctkis] oil 

/\u*bonr\obilc 

o\e*tCs3 oil 


itself. 

itself. 

itself. 

itself. 

itself. 

itself. 

itself. 


You may have 
"to add dh ll s w 
ov- S wo\rd ov- 
two io make 
SCh-tchdC 

readable. 


u should V^avc 七 ho — 七 dav-c-fully 
about *t^is o\r\C) 3 ^d v/i r > 3 't 

medrts. Tills IS a mC*t^od jus*t 

v*ctuv*^s o*P oil 

automobile … ad -bKa-b js somc-tWm^ 
*bV^a*b *bV^c au*tow>obilc should do. 


V 


Follows 

SRP 


Violates 

SRP 






iThis ohc was a little 
i\ri^ky... wc thought that 

f ile 扣 au-tomobile M 

s ^i Sv\d s-fcop itself, i 仏 
Wily the ^rcspohsibilty ^ a 
乂 ― dHv C the 


I§§ 5 S; 

you<r OWh ^pcHc^e. 
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design principles 


ftoiwg from multiple responsibilities 
to a single responsibility 


Once you’ve done an analysis, you can take all the methods 
that don’t make sense on a class, and move those methods to 
classes that do make sense for that particular responsibility. 


I^s 


S\S 




Wc VAScd OVAr 
{jo out tv>at 

W ^ 

vcaW'/ avwt 



\\as or\ly a s'm^lc 

vcspoir\s*ib»l»*tY ： 

v/rth Vts 


ovm 


bdsi£. -fuy\t*bioir\s 


Automobile 


start() 

stop() 

changeTires(Tire [*]) 
drivef) - 


checkOilf) 

getOilQ: int 


a dirivc^s 

ssr 





A Cav-lVash 

y/dsWm^ By\ 
u*bomr\obilc- 


_Mechanic_ 

I changeTires(Automobile, Tire [*]) II 


A is \rcspohsiblc -fov 

dhah 9 ih 9 ahd 

*thc oil oh dh du'tomobilc. 




ther, are no . 

Dumb Questions 


How does SRP analysis work when a method takes 
parameters, like wash(Automobile) on the CarWash class? 


But what if CarWash took in an Automobile parameter 
as part of its constructor, and the method was just wash()? 
Wouldn’t SRP analysis give you a wrong result? 


Good question! For your SRP analysis to make any sense, 
you need to include the parameter of the method in the method blank. 
So you would write "The CarWash washes [anl automobile itself." 
That method makes sense (with the Automobile parameter), so it 
would stay on the CarWash class. 


It would. If a parameter that might cause a method to 
make sense, like an Automobile for the wash () method on 
CarWash, is passed into a class’s constructor, your SRP analysis 
might be misleading. But that’s why you always need to apply a good 
amount of your own common sense and knowledge of the system in 
addition to what you learn from the SRP analysis. 
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ultf \bt rodr dial rbwd it -fkinr ffar» ih^ 
dan, kihI pin iL Enlu> tur Doifloor emir: 




p^niie ： elf j* 叫 物 r 4 
public Yaid opentP [ 

时 3 ten ^ om prin^ln t^fhe 
otx-n a true; 


1^4 ^oor 




firiil TkiMT tlBAr _ 
tiiiwr ■ ■chwlul— (n#w 
public void nm( 
gIdh C> i -— , 
tin»r-CJO!i£Mil (] 


种 p« iw N 以 

aslic y&i 4 clfseO « 

S^ate-n. Nit. print Ln ["The ^ cles« a 


J 


■ 


Sjwplifying th€ remote control 

VoulQ EW^ri D-J l^tol i±ni^ f iwif «tt L-/ Bf—nU* 

Ihr *k^ 4ktui: londln nrlwDifttally dwinf itsri£ 

^dbilc wLd I 

$y PC4 H ,*yit ■: "Pl***^ 
it■! 

i.i i 

k * 1 ** 4 


fyfi irfi&i s^uLttfln* m ■ 


find the single responsibility principle 

r®PSlgtolgS 


The SRP has already made a few appearances in our work so far; now that 
you’re getting familiar with the SRP, it’s time for you to figure out where and 
how it’s been used. Your task is to look at the page below and figure out how 
SRP was used, and why. 


■"This is *(Vorh "the 
[°9 ^ooy, ba^k ih 

'hap-teir Z. 
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How do you think the Single Responsibility Principle was used in Todd and Gina’s dog 
door? Write your answer in the blanks below: 


Now see if you can find two more instances in the book’s examples so far where we’ve 
used the SRP to make our design better and more flexible. You can find the SRP in the 
dog door, Rick’s instrument inventory searcher, or Gary’s game framework. Write down 
each instance you found, and how you think the SRP is being used. 


First Instance 

Example application: _Rick’s Instruments _Doug’s Dog Doors _Gary’s Games 



o 


Example application: — Rick’s Instruments — Doug’s Dog Doors 
How SRP is being used: 
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finding single responsibility 


®P Si^bSu^S Revealed! 

Let’s look back on the times that SRP has already shown 
up in our software. Here are the SRP sightings we came 
up with; see if your answers are similar. 



UpdatEiig the dog door 

]jVt utf itv crdf* than rtwd ihtf 
r|jmb uhI pin iL silU 9 uuT Doifltoor emir: 


ti»r. achwliil^ (iww TiB*irT*Blk(J i 
piJallc void nm(J« I 
clDMi f ) i ^ 

t 邮 

] ■ 七 4 lf.- if w 

I, ^OOg-t t Kv « 4 - 

ihb Aw 

«iic closets \ 

Sys ten. , print In ["The ctwr 

卓辦 ■ 


YoulQ D-J utt- l^tol iUHt- WlCdT Wmal — CttiK. 

Ihr *k>^ 4ktur, Ikondln julwaiftcalty rlMin| rbd£ 

if l 

8 ^ 3 ： I k J 


]p 
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[° 9 心饮， ba^k ih 

'hap-teir Z. 
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How do you think the Single Responsibility Principle was used in Todd and Gina’s dog 
door? Write your answer in the blanks below: 

We moved the code to close the doa door out of Remote.iava. and avoided 、 

duplicating the same code in the ParkRecognizer (PRY in effect there!). We 

also made sure that thelogPoor class haMIcd all tasks relating to the 

operation of the dog door ^ it has that single responsibility. 

Now see if you can find two more instances in the book’s examples so far where we’ve 
used the SRP to make our design better and more flexible. You can find the SRP in the 
dog door, Rick’s instrument inventory searcher, or Gary’s game framework. Write down 
each instance you found, and how you think the SRP is being used. 


fW’s what wc 
wvote about 

how S/^p 

放 VO helped us 
out with the 

doj doov. 


First Instance 

Example application: Rick’s Instruments 


Doug’s Dog Doors 


How SRP is being used: 

We created a matchesH method on liistrumeiitSpec, rather than leaving 

the code to compare instrumewts m the searchH method of Ihvehtory. So an 

IhstrumentSpec handles everything related to an instrument's properties— 

that code isn't spread out over other classes. Thafs SRP m action. 


Second Instance 

Example application: _Rick’s Instruments 


How SRP is being used: 


Gary’s Games 

x/ou Aor：i lo 

wa kc sure syy 

^as “ 一 

七 • 七 . 


Doug’s Dog Doors ^TGary’s Games 


When wc used a Map to store properties for all types of units in the Unit 

class, we were using the SIR So inste^iof having qame-$pecific Units have 

to deal with their properties, and still have the base Unit class dealing with 

a different set of properties we wioved all property-related fmictioMality 

into the nit class. So handling the properties feature is taken care of in 0N£ 

single ftlacc—the Unit class. 
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liskov substitution principle 


Contestant # 4: 

The Liskov Substitution Principle (LSP) 

Next up in our design principle parade is the Liskov Substitution 
Principle, or the LSP. It’s definition is as simple as it gets: 




OK, earlier you convinced 
me that the OCP is more than just 
basic inheritance, but here you are 
with the subclassing thing again. Were 
programmers, we know how to use 
inheritance correctly by now. 


The LSP is all about we[l-designed 
inheritance. When you inherit from 
a base class, you must be able to 
substitute your subclass for that 
base class without things going 
terribly wrong. Otherwise, you’ve 
used inheritance incorrectly! 
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design principles 


Misusing subclassing: a case study iw 
misusing inheritance 

Suppose that Gary’s Games has a new client who wants to use their 
game system framework to create World War II air battles. They 
need to take the basic Board base type, and extend it to support a 
3-dimensional board to represent the sky. Here’s what they’ve done: 


TW»s is ?>o»rA 

base 从 

developed batk m 


S'mtc Boavd^P 

V-CCyu'lV-CS ( 夂々 ， 2 ^ 

c.oov-dma*tcs, \*t adds 

a o-f 
wC ^ods {p su^o^r-t 

C.oovmd3"bcs. 





getTile(int, int): Tile 
addUnit(Unit, int, int) 
removeUnit(Unit, int, int) 
removeUnits(int, int) 
getUnits(int, int): List 



3DBoard 

zpos: int 

3dTiles: Tile [*][*][*] 

getTile(int, int, int): Tile 
addUnit(Unit, int, int, int) 
removeUnit(Unit, int, int, int) 
removeUnits(int, int, int) 
getUnits(int, int, int): List 


㈣ dcsi 3h ， s 
s ^^scd Bo 釙 d 

f hd ㈣ cd “ cw 
七 奶 Board. 


山 va is 


-tKveads Ca-t 

:: S)o_ 


Make i-t S-tidk 


One of these things is just like another. 
Use the base or its subclass, ifs not a bother. 
Substitute, exchange, it doesn't rattle me. 
They all work the same, they use the LSP! 
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Isp reveals inheritance problems 

LSP reveals hidden problems with 
your mheritance structure 

At first glance, it may seem like subclassing Board and 
using inheritance is a great idea. But look closer, there are 
lots of problems that this approach creates: 



subclasses Boavd, 

acts all 

m add»W 
to ^ wC ^ ods 

vb dc^^ cs * 


getTile(int, int): Tile 
addUnit(Unit, int, int) 
removeUnit(Unit, int, int) 
removeUnits(int, int) 
getUnits(int, int): List 


But {htst avc 
七 methods 七 1 ^七 

>MOV-k W\{}\ 
C.oovdima*tcs... so 

y/iia*b d'»d v-cally 

-fvom sub^l 3 ssir\^ 
Boa\rd -type? 


^ 11 f ^ 叱 methods, 

"t^T ： ^\rc ihKe\ri-ted 

ko 州 Boaird doh'-t 

have 釙 y meahihQ i h 
^ 9 


The 3DBoard class is not substitutable 
for Board, because none of the 
methods on Board work correctly in a 
3D environment. Calling a method like 
getUnits(2, 5) doesn’t make sense for 
3DBoard. So this design violates the LSP. 


f.vcv\ >wovsc, 

(W 七 kv^OY/ 

七 f ass'm^ a 

6oovd'ma*bc l'»kc 
^PBoavd- TW»s 
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"Subtypes must be substitutable 
for their base types" 

We already said that LSP states that a subtype must be 
substitutable for its base type. But what does that really 
mean? Technically, it doesn’t seem to be a problem: 


Board board = new 3DBoard(); 


Fv-om domfilers po'm*t o( 
view, iVdoard be used m 
f>lade a Boav-d hcvc- 



But when you start to actually use that instance of 3DBoard 
like a Board, things can get confusing very fast: 


Unit unit = board•getUnits (8, 4); 


Rcmcmkcv, koavd \^€Ct »S 

adWlv o^r th 

^PBoavd- 


Bu*t what docs this method 

oh ^PBoav-d? 


So even though 3DBoard is a subclass of Board, it’s not 
substitutable for Board... the methods that 3DBoard 
inherited don’t have the same meaning as they do on the 
superclass. Even worse, it’s not clear what meaning those 
methods do have! 


Ir)he\riia^e (ar>d the LSP) mdidatc 

3r\y rv\C"thod ov\ Bo3\rd should 
be able -to be used ov\ ?DBoavd... 

七 hat ZVdoard stand m 

Board v/iihou-t any p\roblcrws. 


Some brt d todc tails a 
method -fv-om Boav-d, lou*t 


oy\ m 


sta^dc o( 3>PBoavd- 



Bu 七 do "these 
•^C*thocls *Pov* 

^VBoavd? They pvobabl> 
doh 七 』 
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avoid confusing code 


Violating the LSP makes for confusing code 

It might seem like this isn’t such a big deal, but code that violates LSP 
can be confusing, and a real nightmare to debug. Let’s think a bit about 
someone who comes to use the badly designed 3DBoard for the first time. 


They probably start out by checking out the class’s methods: 


3DBoard 



^tt\ some 

o( *tKcsc mctiiods 
avc^*t dc-f med oy \ 

3>PBoavd, -tKcyVc all 

*mKcV*l*tcd -fv-orr» 
base dlass, Boavd. 


width:int 
height: int 
zpos: int 
tiles: Tile [*][*] 

3dTiles: Tile [*][*][*] 

getTile(int, int): Tile 
getTile(intTint, int): Tile 
addUnitdJniLinLint) 
addUnit(Unit, int, int, int) 
removeUnit(Uniyny nt)_ 
removeUnit(Unit, int, int, int) 
removeU n its(i nt 丄 int) 
removeUnits(int, int, int) 
qetUnjts(int, int): List 
getUnitifint, int, int): List 


Hmm, I'm not sure which 
version of getTile() and addUnit() to 
use. Maybe those methods take an X- and 
Y-coordinate for the current board... I'm 

just not sure. 


O 


It’s hard to understand code 
that misuses inheritance. 

When you use inheritance, your subclass gets 
all the methods from its superclass, even if 
you don’t want those methods. And if you’ve 
used inheritance badly, then you’re going to 
end up with a lot of methods that you don’t 
want, because they probably don’t make 
sense on your subclass. 

So what can you do to avoid this? First, be 
sure your subclasses can substitute for their 
base types, which is just following the LSP. 
Second, learn about some alternatives to 
using inheritance in your code... 
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Solving the JPPoard problem 
without using iwhcritawcc 

It’s not enough to just know that inheritance isn’t the answer... 
now we’ve got to figure out what we should have done. Let’s look 



at the Board and 3DBoard classes again, and see how we can 
create a 3-dimensional board without using inheritance. 


Ir^sicad Jc cx-tchsioh, wcVc usihA 

ah ^sso^ia-tioh. So ^DBoavd 
^ use -the behavior of Boa^d, 

v^ithout having -fco extend -fvom 

it ahd violate -the LSp. 

: 办 。 ^ 吹 - 

dc ， c ^iJiU e T' f hd iheh 

ci:r ds ^ 




getTile(int, int): Tile 
addUnit(Unit, int, int) 
removeUnit(Unit, int, int) 
removeUnits(int, int) 
getUnits(int, int): List 


getTile(int, int, int): Tile 
addUnit(Unit, int, int, int) 
removeUnit(Unit, int, int, int) 
removeUnits(int, int, int) 
getUnits(int, int, int): List 


TV^c Boavd tlass V^as 

WW 、 切 , 滅 f= 

,eeds, Wt ^ base 

切 ? e k ^P^oavd- 



乙 a 灼 

s*toV"C 3^ 3VV"3Y 

Boavd 
lobjcC-*bs) Sy'ci 
l^d a 

|3>P dollc6*t'»oy\ 
boards. 


TW»s \s a ^ovm dele—^i. 
TV ^PBoavd tlass delegates 
a U*t d vb WWah 七 Y ^ 

七 rndWidudl Boavd msiav^cs. 


These methods look a lot 
like 七 he methods m Board ， 
but they y\ttd to use the 
-fu^dtio^alrty m Boav-d, v-athev* 

灼 wbe^d i*t. So mhcv-i*ta^c 




So what options arc there besides iwheritawee? 
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use another class’s functionality 


delegate fuwctiowality to another class 

You’ve already seen that delegation is when one class hands off the 
task of doing something to another class. It’s also just one of several 
alternatives to inheritance. 



Delegation is when you hand over 
the responsibility for a particular 
task to another class or method. 


Delegation was what we used to solve the 3DBoard problem we’ve 
been looking at, without resorting to inheritance: 


^cjusi 

about 

^clcga-tioh. You 
usc ^ 

^sodia-tioh |i hC 


getTile(int, int): Tile 
addUnit(Unit, int, int) 
removeUnit(Unit, int, int) 
removeUnits(int, int) 
getUnits(int, int): List 




3DBoard 

zpos: int 

3dTiles: Tile [*][*][*] 

getTile(int, int, int): Tile 
addUnit(Unit, int, int, int) 
removeUnit(Unit, int, int, int) 
removeUnits(int, int, int) 
getUnits(int, int, int): List 


3>p3oavd 

dclcoyatcs 

boards to 
^ tlass. 
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Whew to use delegation 

Delegation is best used when you want to use another class’s functionality, 
as is, without changing that behavior at all. In the case of 3DBoard, we 
wanted to use the various methods in the Board class: 


Board 

width:int 
height: int 
tiles: Tile [*][*] 

getTile(int, int): Tile 
addUnit(Unit, int, int) 
removeUnit(Unit, int, int) 
removeUnits(int, int) 
getUnits(int, int): List 


Thp methods all … 
lh 心此 wc wairt "to s-tovc dh 
chth amray o( Boards, ahd 
thch use ihdividual Boavd 
via "these methods. 



Since we don’t want to change the existing behavior, but we do want to 
use it, we can simply create a delegation relationship between 3DBoard 
and Board. 3DBoard stores multiple instances of Board objects, and 
delegates handling each individual board-related task. 


3DBoard 

zpos: int 

3dTiles: Tile [*][*][*] 


getTile(int, int, int): Tile 
addUnit(Unit, int, int, int) 
removeUnit(Unit, int, int, int) 
removeUnits(int, int, int) 
getUnits(int, int, int): List 


llsfov/ 1>PBoavd uses *tV\c z. 

6oovd'ma*tc -to yt a Boav-d 
msta^c m av^aY ， a^d 
dclqa 七 cs 仫 a method 
on 铷 a*t Boavd ^ -bV^c 

sullied ^ av^d Y dooyrdmates. 


Board 


width:int 
height: int 

tiles: Tile [*][*] 


getTile(int, int): Tile 
addUnit(Unit, int, int) 
removeUnit(Unit, int, int) 
removeUnits(int, int) 
getUnits(int, int): List 


H you need to use iunctionality in anotker class ， 
tut you don’t want to ckange tkat : functionality ， 
consider using delegation instead oi inkeritance* 


you are here ► 


407 

















use multiple classes’s behaviors 


Use composition to assemble behaviors 
from other classes 

Sometimes delegation isn’t quite what you need; in delegation, the behavior 
of the object you’re delegating behavior to never changes. 3DBoard always 
uses instances of Board, and the behavior of the Board methods always 
stay the same. 

But in some cases, you need to have more than one single behavior to 
choose from. For example, suppose we wanted to develop a Weapon 
interface, and then create several implementations of that interface that all 
behave differently: 


attack)) 


attackQ 


«interface» 

Weapon 



Weapon dc-Pmcs 

attadkO me 七 hod … 



...and -tV^csc cftaW s 
d all dcW 

ba 七 wc 七 W. 


Now we need to use the behavior from these classes in our Unit class. 
One of the properties in our properties Map will be “weapon”，and 
the value for that property needs to be an implementation of the Weapon 


class. But a Unit might change weapons, so we don’t want to tie the 
weapon property to a specific implementation of Weapon; instead, we just 
want each Unit to be able to reference a Weapon, regardless of which 
implementation of Weapon we want to use. 


TV^cv-c s a 




)) 


Wlc do^*b y/3K\*b *to be s*bu 乙 k 

ov\t pav-ti^ulav- ms-bcad, 

v/e war\*b -to cMoost ⑼七 lie 
available weapon types. 


tW、s wa? 匕表 d 


Unit 

type: String 
properties: Map 

setType(String) 
getType(): String 
setProperty(String, Object) 
getProperty(String): Object 


-tha-t wc waht io 
associate with 

"the lA/fcapoh ihteA 匕 e 


«interface» 

Weapon 


attackf) 
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design principles 


Whew to use composition 


When we reference a whole family of behaviors like in the Unit 
class, we’re using composition. The Unit’s weapons property is 
composed of a particular Weapon implementation’s behavior. We 
can show this in UML like this: 




Unit 

type: String 
properties: Map 

setType(String) 
getType()： String 
setProperty(String, Object) 
getProperty(String): Object 


a Wca ? oyj, a^d 

UJ cs 

a ok 

subclasses bjjt 

d ^a ? o^, so ： 

Jfov tV^c 代 laW 如？ 

feeWe ， a,d 



1^^ 

>word 

L 

1 一 


I.., Gun , 


1^ 


The? subclasses o( tV capoh 
扣 c all substi-tu-tablc 4^ 

l^apoh, so ihhciri-feah^c is a 

_9 ood 匕 k m this 


Club 


attack)) 



Composition is most powerful when you want to use behavior defined 
in an interface, and then choose from a variety of implementations 
of that interface, at both compile time and run time. 



Composition allows you to 
use behavior from a family of 
other classes, and to change 
that behavior at runtime. 



P,2 ^ is dually a yrcai cx— 

匕 ompositioh. i 仏 Composed d 
ihAlrcdich-ts, but you swap o 
ihgircdichts without i 
ov ^H piz^a slide. 





Jf yjc CoWare 


;r;: 二口 ;“ ^ 
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composition and ownership 


Whew the pizza is gone, so arc the 
ingredients... 


There’s one important point we haven’t mentioned so far about 
composition. When an object is composed of other objects, 
and the owning object is destroyed, the objects that are part of the 
composition go away, too. That’s a little confusing, so let’s take a 
closer look at what that actually means. 


Here’s our Unit class again, which has a composition 
relationship to the Weapon interface and its implementations : 



Suppose we create a new Unit, and assign its weapon property 
to an instance of Sword: 






Unit pirate = new Unit(); 
pirate . setProperty (''weapon 


/ 


n 


new Sword()) 


f 



This Uh'ri is 
Composed v/iih 
ihs-bh^c of 
Swo\rd. 

〆 


—I Unit X 



What happens if this Unit is destroyed? Obviously, the 
pirate variable is trashed, but the instance of Sword 
referenced by pirate is also thrown away. It doesn’t exist outside of 
the pirate object. 



… 诎⑼ y° u ^c airtoW 心 lly 
gcUihg Hd o( the Wd obi 故七 
associated with pivatc, -too. ° 


V 

丁 Wis Sv/ovd object 
does v\o*b 

pav ■ 七 • 丨〜 lav* Uht 
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design principles 


In composition，tke object composed ol otker 
tekaviors owns tkose tekaviors* Wken tke 
object is destroyed, so are all ol its tekaviors* 

Tke tekaviors in a composition do not exist 
outside ol tke composition itselt 


o 


I get it... composition is 
really about ownership. The main 
object owns the composed behavior, 
so if that object goes away, all the 
behavior does, too. 






Can you think of an example where the ownership 
aspect of composition would be a negative in your 
application? When might you want the composed 
objects to exist outside of the composing class? 
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aggregating behaviors 


Aggregation: composition without 
the abrupt ending 

What happens when you want all the benefits of 
composition — flexibility in choosing a behavior, and adhering 
to the LSP — but your composed objects need to exist outside 
of your main object? That’s where aggregation comes in. 



Aggregation is when one class is 
used as part of another class, but 
still exists outside of that other class. 



The i 以 bdhahds ； dhd 

•Vies cxis-t ou-bidg 心 
split. Take away tha-t 
hay ayyd you vc still 

3 。七 the ihdividual £ompoheh-ts. 


YouVe already used aggregation... 

We’ve been using aggregation already, in Rick’s Stringed 
Instruments, from Chapter 5: 


ImC Y/rth a 灼 

diamond a 七七 ad 

a^v-c^at'oyv. 



“ sed 

(lik ： ‘~: by ,hSw 


a 


Instrument 

serialNumber: String 
price: double 


getSerialNumber(): String 
getPrice(): double 
setPrice(float) 
getSpec(): InstrumentSpec 


spec 


1 



InstrumentSpec 

properties: Map 

getProperty(String): Object 
getProperties(): Map 
matches(lnstrumentSpec): boolean 


\A/c able *to avoid 

all tUsc 

s ^\t suUlasscs V>7 — 

a 奶 rcyW 一 . 
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Aggregation versus composition 

It’s easy to get confused about when you should use composition, 
and when you should use aggregation. The easiest way to figure 
this out is to ask yourself, Does the object whose behavior I want to use 
exist outside of the object that uses its behavior? 

If the object does make sense existing on its own, then you should 
use aggregation; if not, then go with composition. But be careful! 
Sometimes the slightest change in the usage of your objects can 
make all the difference. 




Pive-Mixiiite Mystery 

Joel leaned back in his seat, arched his back, and thought again 
about buying that new Aeron chair once his stock options came 
in. Being a game programmer was hard work, and Joel was the last 
coder in the office yet again. 

“People are gonna go nuts over Cows Gone Wild,” he thought. He 
pulled up the user guide for Gary’s Game System Framework, and 
started to think about how he was going to implement the cowboys, 
one of the last features he had to deal with. Suddenly, his eyes lit 

upon the Unit class, and he realized that he could 
use Units for cowboys, and the Weapon interface 
for lassos, revolvers, and even branding irons. 



Joel created Lasso, Revolver, and Brandinglron 
classes, and made sure they all implemented the 
Weapon interface. He even added a Weapon property 
to his Building class, so the cowboys could hang their gear up at the 
end of long days chasing the cows. 

‘This is so money... a little bit of composition, and I’ll bet boss- 
man Brad will put me as the lead designer in the game credits.” 

He quickly drew up a class diagram of what he had done for the 
morning shift, colored in his composition diamond between the 
Unit and Weapon classes, and headed for Taco Bell on the way 
back to his apartment. 

Little did Joel know that when he got back into work the next day, 
Brad would be yelling at him, instead of congratulating him... 

What did Joel do wrong? 


§^^uo J—suy ▲ 
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going beyond inheritance 


Inheritance is just one option 

We started out this section talking about the LSP, and the 
basic idea that subclasses must be substitutable for their 
base classes. More importantly, though, now you have 
several ways to reuse behavior from other classes, beyond 
inheritance. 


Let’s take a quick look back at our options for reusing 
behavior from other classes, without resorting to subclassing. 



Delegation 

Delegate behavior to another class when you 
don’t want to change the behavior, but it’s 
not your object’s responsibility to implement that 
behavior on its own. 



Composition 


You can reuse behavior from one or more 


classes, and in particular from a family of 
classes, with composition. Your object 
completely owns the composed objects, and they 
do not exist outside of their usage in your object. 



Aggregation 

When you want the benefits of composition, 
but you’re using behavior from an object 
that does exist outside of your object, use 

aggregation . 


If you favor 
delegation ， 


composition, and 
aggregation over 


inkeritance, your 
software will 


usually te more 
: Rexilile，and easier 
to maintain ， extenct ， 
anct reuse. 
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ther, are ng . 

Dumb Questions 



I thought subclassing was a good 
thing. Now you’re saying it，s a bad thing? 

No, subclassing and inheritance 
are key to any good 00 programming 
language. The LSP is not about subclassing, 
though; it’s about when to subclass. If your 
subclass really is substitutable for its base 
type, then you’ve probably done a good job 
using inheritance. If your subclass is not 
substitutable for its base type, then you might 
look at other 00 solutions like aggregation 
or delegation. 

But it is OK to use delegation, 
composition, or aggregation in a class 
that really shouldn’t extend another 
class? 

A! Sure. In fact, the LSP doesn’t apply 
at all to aggregate or delegate classes, 
because those are two great ways to fix 
an inheritance tree that doesn’t conform to 
the LSP. You might even say that good use 
of the LSP goes hand-in-hand with more 
delegation, composition, and aggregation. 


Do we really need to apply the 
LSP all the time to figure this out? Isn’t 
this just writing good 00 software? 


Lots of times, you don’t need to 
worry about the formal name of a design 
principle to write good code. For example, 
look back at the Board example on page 
401; to make 3DBoard extend Board, 
all of the methods had to be changed! That 
should be a real tip-off that you’re got some 
inheritance problems. 


There were a lot of weird UML 
symbols in there. How am I supposed to 
remember what they all mean? 


A! You really don’t need to memorize 
these symbols at all. While UML provides 
specific notation for aggregation and 
composition, they are all just different forms 
of association. So just like we did with 
delegation, you can use a normal line with an 
arrow, a normal association, for composition 
and aggregation. 


乂 . But won’t that be confusing to 
developers if they don’t know what type 
of association should be used? 

A! That’s possible, but it also allows for 
a lot more flexibility. Suppose that you decide 
later on that when an army is destroyed, you 
don’t want the individual units destroyed as 
well. So you might change the relationship 
between army and unit from composition to 
aggregation. 

If you’re using a basic association arrow, 
you won’t need to change your class 
diagram at all. It also gives the developer 
freedom to come up with their own ideas 
about how to implement the association. 

There's nothing wrong with using the 
aggregation and composition symbols, 
but you shouldn’t get too hung up on 
it, especially if you’re early on in the 
development cycle. You never know what 
might change later, and flexibility is always 
better than rigidity in your design. 
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who am i? 



A bunch of classes involved in 00 principles, all in full costume, are 
playing a party game, “Who Ami?” They give a clue, and you try to 
guess who they are, based on what they say. Assume they always 
tell the truth about themselves. If they happen to say something that 
could be true for more than one of them, choose all for whom that 
sentence can apply. Fill in the blanks next to the sentence with the 
names of one or more attendees. The first one’s on us. 

Tonight’s attendees: 

Subclass Delegated Class Aggregated Class 
Delegating Class Composite Class 


I’m substitutable for my base type. 

I let someone else do things for me. 

lvly benavion^ise^is part of 
another class’s behavior. 


I change the behavior of 
another class. 


I don’t change the behavior 
of another class. 


I can combine the behavior of 
other classes together. 

I’m not gonna go away，even 
if other related classes do. 


I get my behavior and 
functionality from my base type. 


► TJnitiasI^ the principles on pa^e 420 
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design principles 


BULLET POINT 



■ The Open-Closed Principle keeps your software 
reusable, but still flexible, by keeping classes open 
for extension, but closed for modification. 

■ With classes doing one single thing through the 
Single Responsibility Principle, it’s even easier to 
apply the OCPto your code. 

■ When you’re trying to determine if a method is 
the responsibility of a class, ask yourself, Is it this 
class’s job to do this particular thing? If not, move the 
method to another class. 

■ Once you have your 00 code nearly complete, be 
sure that you Don’t Repeat Yourself. You'll avoid 
duplicate code, and ensure that each behavior in 
your code is in a single place. 

■ DRY applies to requirements as well as your code: 
you should have each feature and requirement in 
your software implemented in a single place. 

■ The Liskov Substitution Principle ensures that you 
use inheritance correctly, by requiring that subtypes 
be substitutable for their base types. 


■ When you find code that violates the LSP, consider 
using delegation, composition, or aggregation to 
use behavior from other classes without resorting to 
inheritance. 

■ If you need behavior from another class but don't 
need to change or modify that behavior, you can 
simply delegate to that class to use the desired 
behavior. 

■ Composition lets you choose a behavior 
from a family of behaviors, often via several 
implementations of an interface. 

■ When you use composition, the composing object 
owns the behaviors it uses, and they stop existing as 
soon as the composing object does. 

■ Aggregation allows you to use behaviors from 
another class without limiting the lifetime to those 
behaviors. 

■ Aggregated behaviors continue to exist even after 
the aggregating object is destroyed. 
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ooa&d toolbox 



Tools for your 00A 备 P Toolbox 

We’ve got a lot more OO principles to add to 
the toolbox. Let’s add what we’ve learned to our 
notes — and remember: these principles are best 
used together, not separately! 




6\ooA \rc<\u*»\rci 

y/ov-ks like y o, | 咖一 des 吵 ed *»s easy -toH 

Make suv-e Y<fl 扣 d e% 七⑶ d ， 

Use basit UU fvmcifies iirc c 

Use y 
■tWmy y 

|^ou\r us J Er>6a\>sula*tc 丄七 varies, 
ov ^\ssm Code *to ar> m-tc^adc ra-tKc^r *tv>ar> -to ar> 




Listch -to -the duster^ ad -Pijuvc ou-t 
v/M： ihey waht you build. 

a lisi \ a ^ c 

the dus-tomc\r t»hde\rstahds. 


00 Pvm^tplcs 


have. 


you\r v-c 

yOY/) ■ 


EadK dlass *rn your a 代 katio 於 should Kavc o^ly 

ov>e veaso^ *to dV>a»>y 

Classes arc abou 七 bcKavtov ay>d ‘6 七咖 alrb/. 

Classes should be o ? cr> U W 七 closed 

-fov mod*i-f ^a*t*ior> (*tV>C OCP) 

/\vo*id du?ka*tc 6odc h abstvad-tm^ out 七^呼 
从 a 七 arc dommor> a^d \>la6 吒佔⑽ m a sm^lc 

loda-tio^ (*tv>c PRY 

^vcvv ob\cdl *m your system should V>avc a 
—1c 叫咖 ibilrb/，and all ^ obje^s s^vtde 
should be -fodused carr^ ou-t sm^lc 
vcs)[>or>s*ib*iri"bY (*tV>c SRP) 

Subclasses should be suitable -for *tKc*i\r base 
classes (七 V>e LSP) 


-PcaWs avc what the 

a 匕 "tidily wairts. 

■: "ts of the usihg use 

^Hahd use ^ascs). 

h lystcm up ih-fco lo-ts of 

: ions 


: -tcVhS *to -the smallev* 
ysiem. 


s 


pHh^ipIcs io desigh ahd 

sc^-tioh. 
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OOA&D Cross 

This one is a particularly tough puzzle ： almost all the 
answers are more than one word. Good luck, and keep 
that left brain working. 



Across 

1. A vanotion cm compositian. 

3. This when one abject owns behaviors fram 
other objects. 

6. This is when you hand over raspons^biiity far 
a particular behavior, 

7. He wqs afl about subgth"uti on_ 

S. Thfi L5P reveals prabfems refated to this. 

1L y^y shmild keep a dngJe p^ece cf cade m 
many Traces. 

13, You ^hoylld have each piece of ycur 
mfarmaiiDn and this in a single, sensible pbce. 

14„_out things that are common in 

your cede. 

15. Each object in your should hove this 

many raSpon^ibNities, 

16. Th\^ is overrated m good 00 Software 

17. Another term for SRP b this.. 


bawn 

2. Aggregated obj&cts exi^t _ of the 

cf asses that use them. 

4. Subtypes must be substitutable for the^e. 

5. fTfa^ses should be closed far this,. 

9. OQ principled work best when used this way. 

10. A we]I-designed c\a^^ hos only ane reci^an ta 
do this, 

12. Clines should be open for this. 
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exercise solutions 



A bunch of classes involved in 00 principles, all in full costume, are 
playing a party game, “Who Ami?” They give a clue, and you try to 
guess who they are, based on what they say. Assume they always 
tell the truth about themselves. If they happen to say something that 
could be true for more than one of them, choose all for whom that 
sentence can apply. Fill in the blanks next to the sentence with the 
names of one or more attendees. The first one’s on us. 

Tonight’s attendees: 

Subclass Delegated Class Aggregated Class 
Delegating Class Composite Class 


I’m substitutable for my base type. 

I let someone else do things for me. 


subclass 


My Denavldl 1 \s as part of 
another class’s behavior. 


dele 今 a 七 dlass ； dom^osi-be dass 

acwre<\aied dass 


-TWis is a V>as'»6 
Ut a tlass 


I change the behavior of 
another class. 


I don’t change the behavior of 
another class. 


I can combine the behavior of 
other classes together. 


A subclass is 
"the ohly ^lass 

that 匕 hdhfljes 

ahothcv- ^lasss 
bchaviov-. 

dom^osi-be dlass, dass 


dele^aied dlass, dlass, ^ 

ddeoja-bih^ dlass, domposi-be dlass 


I’m not gonna go away，even if 
other related classes do. 

I get my behavior and 
functionality from my base type. 


a^ye^aied d3ss, dele^aied dlass 


subclass 


aW 脚 W ， 

object 

avc 

op 
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Pive-Mixiiite Mystery Solved 


Joel’s big mistake was revealed in this line: 

He even added a Weapon property to his Building class, so 
the cowboys could hang their gear up at the end of long days 
chasing the cows. 


When Joel decided that cowboys could hang up their weapons, 
he committed to the Lasso, Revolver, and Brandinglron classes 
existing outside of any individual Unit instance. No cowboy owned 
the gear; they just used the behavior of the gear for a time. 

Since the Weapon implementations exist outside of a specific 
cowboy, Joel should have used aggregation instead of composition. 
Different cowboys could use the same Weapon implementation at 
different times, and those weapons should stay in existence, even if 
the cowboy using them was trampled by a mad cow. 
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iterating and testing 


The Software is Still 



for the Customer 


I spent forever wondering 
what I could give you to show 
how much I think of your ideas, 
and then I had it ： a beautiful 
a new set of tests! 


- 


It’s time to show the customer how much you really 


Care. Nagging bosses? Worried clients? Stakeholders that keep asking, 


“Will it be done on time?” No amount of well-designed code will please 


your customers; you’ve got to show them something working. And now 
that you’ve got a solid 00 programming toolkit, it’s time to learn how you 
can prove to the customer that your software works. In this chapter, we 
learn about two ways to dive deeper into your software’s functionality, and 
give the customer that warm feeling in their chest that makes them say, 
Yes, you^e definitely the right developer for this job! 
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kick-ass developers 


Your toolbox is filling up 

We’ve learned quite a bit so far, and our toolbox of analysis 
and design tools is getting pretty full. We even added some OO 
programming techniques in the last chapter: 



緣. 


Requi\rewften-fcs 



^^alysis aiad Desi^ 

Well - dksi 沪 cdl is easy b> 乩 

ar\d 

Use basid 00 ^v'md'^lcs like capsulation 
a^a 

more 


从 ve 3 ot a Whole slew 
P^^.plcs ahd te^hi^ucs 
如产七 h 饮 ，〜也 
如如 ⑽ design 
% solve a || -types o-f 
so+twavc pVoblcrhS. 





U\sjcy\ jo -fch 


l-f a dcsiy I 
|T| Ncvcv I 

•rt’s ^ouy bl 


00 Pvmdiples 


Enta'psulatc vav-'ics. 

Code -to a»> mlcv-fatc v-attev ^ 

你 “ ， •— ⑽ laW. 

OUt Ttt_ Classes a^e about b^av.o^r and 

Classes should be (or extension, but t\ostd 
•for wodi-fitafcor* (ttc 0CP) 

/\vo»a du^r.tatc todt by abstvad^ out 

\otahory (-t^c PRV 

Evcvv object rn your system should V>avc a 
sm^lc vcs^sib-.r.t7, ar»a all objects se^dcs 
Should be -fodused on ou-t ttat sm 少 

vcs^oy»sibir»t/ SRP) 

Subclasses should be salable ttc.v base 

classes (*tV>c LSP) 


Make suve 
ea£-V> yl 
ONE THII 

Always s-t' I 
move -tW« 

|i-fcdY d ^' 


ahd -fi3uvc ou-t 
you -to build. 

a ^ ca ^l c list ； in —uay 

⑽ dm^ahds. 

; 的 what -the 


Isystem usih^ use 
l^ses). 

* ih"to lois o-f 


■ > ihe smallev 


p<ri^iplcs io dcsi3 h a^d 
sc^-tioh. 



匕 D: d 

PP， ^'° h ^hi{ e ^ ulrc 


1 Make sure your 
software ctoes wkat tke 
customer wants it to do. 


TU steps 

-to Y/V»t>V^ 

yea 七 software 
shoY/cd batk 
•m CV^aftev-1, 
ku*t … c’ve \)ttv\ 
us'm^ -tv^cw 
七 Wo — ⑽七 

CVCVY 


2. Apply Lasic 
00 principles to 
add flexibility. 


3. Strive for a 
maintainable, 
reusable ctesign. 
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iterating and testing 


Thafs great, really, you’re an amazing 
developer, Tm sure. But I really don’t 
care about any of that... 

where's my application? 


o 


Put youYc still writing 
your software for the 
CUSTOMER! 

All the tools and techniques 
you’ve been learning are 
terrific... but none of them 
matter if you don’t use them 
to produce great software that 
makes your customer happy. 

And most of the time, your 
customer won’t care about all 
the OO principles and diagrams 
you create. They just want the 
software to work the way that 
it’s supposed to. 



tit ： ^ 
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iterate deeper 


We really don’t have anything to 
show Gary yet. All weve done is 
start on a few of these key features, 
like the Board class and the Unit 
class diagram. 





Joe: Yeah, maybe we shouldn’t have spent all this time on so 
many diagrams, and all this architecture stuff. We’ve got nothing 
to show Gary except a bunch of ovals with things like “Play 
Game” written inside them. 

Frank: Come on guys, we’ve got a lot more done than that. It’s 
going to be simple to finish up the Board class, because we’ve 
already got a start on writing a lot of that functionality. 

Jill: Well, sure, but that’s the only class we’ve written any code 
for. How are we supposed to show that to Gary? 

Joe: Well, I guess we could write the Unit class pretty easily, 
since we did that class diagram. So it wouldn’t take a lot more 


You write 
great software 
iterativel y. 

Work on tke tig 
picture , anct tken 
iterate over pieces 
ol tke app until 
it’s complete. 


time to write the code for that class. 

Frank: Exactly. And, really, we know how to write all of these 
classes. We can just take each class, or even an entire package, 
and apply all those OO principles and analysis and design 
techniques to each chunk of functionality. 

Jill ： But we’ve got to work on functionality now. We don’t have 
time for a bunch more big-picture analysis and design. 

Frank: But that’s just the thing, Jill: we don’t need to change 
what we’re doing, we just need to iterate deeper. 

Joe: Iterate deeper? What does that mean? 

Frank: It just means we keep doing analysis and design, but 
now on each individual part of Gary’s game system framework. 

Jill ： And as we build up the application ， we’ll have lots of pieces 
working that we can show to Gary ， right? 

Joe ： And we get to use all these tools we’ve got to make sure the 
software is well-designed, too, right? 

Frank: Exactly. But first, we’ve got a choice to make... 
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iterating and testing 


Iterating deeper: 
two basic choices 


When it comes to developing software, there is more than 
one way to iterate into specific parts of your application. 
You’ve got to take on smaller pieces of functionality, but 
there are two basic approaches to figuring out which 
small pieces to work on — and even what a “small piece’’ 
means in terms of your application. 

You can choose to focus on specific 
features of the application. This 
approach is all about taking one 
piece off functionality that the 
customer wants, and working on that 
functionality until it’s complete. 



Feature driven development 

"is when you pick a specific feature 
in your app, and plan, analyze, and 
evelop that feature to completion. 


You can also choose to focus on 
specific flows through the application. 
This approach takes a complete path 
through the application, with a clear 
start and end, and implements that 
path in your code. 



case driven development 

.is when you pick a scenario 
through a use case, and write code 
to support that complete scenario 
rough the use case. 



Botli approaches to 
iterating are ctriven 
hy gooct requirements. 


Because recjuirements 
come Irom tke 
customer, liotli 
approackes {ocus on 
ctelivering wkat tke 
customer wants. 
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features or use cases? 


Feature drivcw development 


When you’re using feature driven development, 

you work on a single feature at a time, and then 
iterate, knocking off features one at a time until 
you’ve finished up the functionality of an application. 


Gary's ^amc System Framework 

Feature List 之 

1. The framework supports different types 
of terrain. 

1 . The framework supports different time 
periods, including fictional periods like sci- 
fi awd fantasy. 

$. The framework supports multiple types of 
troops or imits that are game-specific. 

4. The framework supports add-ow modules 
for additional campaigns or battle 
scenarios. 

5 . The framework provides a board made 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose turn 
it is. 

7. The framework coordinates basic 
movement. 


o 


I Poard 

— 



八 

Game Designer 


i 1 — -) LZT] 

View 


1 Utilities 

L_ ■ 上 



°ha, 


dwv - 


So .e lake^eaWe 
#|, av\d >Movk ov\ tV\c 
Tcvram dass, as as 
TWt tlass, s 外 ? M 

秦 wU 7 ? ^ 



Modify Existing Game 




ie Game 



Controller 




tnodeV 



All these o-thc\r pla h s ahd 
d^a^s aire used, but youv- 
list is -the UJ. 
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iterating and testing 


Use case driven development 

With use case driven development, you work on completing 
a single scenario through a use case. Then you take another 
scenario and work through it, until all of the use case’s scenarios 
are complete. Then you iterate to the next use case, until all your 
use cases are working. 
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use case or feature driven 


Two approaches to development 

There’s just one basic way to write code, isn’t there? Well, there 
are actually a ton of different ways to go about iterating deeper 
and finishing up parts of your application. Most of these 
different approaches fall into the two basic categories we’ve been 
looking at, though. So how do you decide which to use? 


Whafs the difference between feature driven and 
use case driven development? 


Feature driven development is 
wore granular 



\s yrcibf 

a^li6a*t'«oy\ V^as a 
jot of 




Works well when you have a lot 
of different features that don’t 
interconnect a whole lot. 


Use case driven development is 
wore "big picture" 



II be wo\rkih0 
pretty 

^jo\T (ihuhks O-P 
toA ^ a 
si ^c a sihale 
^Ch3\rio of-tch 


involves 3 lo-t ^ 


Works well when your app has lots 
of processes and scenarios rather 
than individual pieces of functionality. 


Allows you to show the customer 
working code faster. 


Is very functionality-driven. You’re not 
going to forget about any features 
using feature driven development. 


Works particularly well on systems 
with lots of disconnected pieces of 
functionality. 


Allows you to show the customer 
bigger pieces of functionality at each 
stage of development. 

Is very user-centric. You’ll code for 
all the different ways a user can use 
your system with use case driven 
development. 

Works particularly well on 
transactional systems, where the 
system is largely defined by lengthy, 
complicated processes. 
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命命 命 



Welcome to “Name That Approach!” Below are several statements, and 
each one is about a particular approach to iterating over parts of your 
system. Your job is to figure out which approach each statement refers to. 
Note that sometimes, a statement might apply to both approaches. 


Use Case Driven Feature Driven 


This approach deals with really small pieces 
of your application at a time. 


This approach lets you focus on just a part 
of your application at a time. 


This approach is all about a complete 
process in your application. 


Using this approach, you can always test 
to see if you’ve completed the part of the 
application you’re working on. 


When you use this approach, your focus is 
on a diagram, not a list. 
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name that approach solutions 


命 + 命 

ATT 



Welcome to “Name That Approach!” Below are several statements, and 
each one is about a particular approach to iterating over parts of your 
system. Your job is to figure out which approach each statement refers to. 
Note that sometimes, a statement might apply to both approaches. 


ExeRcfee 

SpLptlonS 


Use Case Driven Feature Driven 


This approach deals with really small pieces 
of your application at a time. 




This approach lets you focus on just a part 
of your application at a time. 


This approach is all about a complete 
process in your application. 




□ 


Using this approach, you can always test 
to see if you’ve completed the part of the 
application you’re working on. 






When you use this approach, your focus is 
on a diagram, not a list. 




□ 
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iterating and testing 


Let's use feature 
driven development 

Since Gary’s losing patience, let’s go with feature driven development. We can 
take just a single feature and work it through to completion, and it shouldn’t 
take as much time as it would to write the code to support an entire use case. 

Anytime you’ve got a customer impatient to see results, you should consider 
feature driven development, and starting with a feature you’ve already done 
some work on. 




Gary's System Framework 

Feature List 


1. The framework supports different types 
of terrain. 

Z. The framework supports different time 
periods, including fictional periods like $ci - 
h awd fantasy. 

多 . The framework supports multipietY^ 
troops or imits that are game-specific. 

4^1^ framework supports add on modules 
for additional campaigns or battle 
scenarios. 

5. The framework provides a board made 
up of square tiles, and each tile has a 
terrain type. 

6. The framework keeps up with whose turn 
it is. 

7. The framework coordinates basic 
movement. 


V\fe already V^avc i\\t t\ass 
*fov so lets 

Y/\r'i*bc Code -fov 从 a*t 山 ss > 

a”d kwk 心 aWc 料 . 


Unit 

type: String 
properties: Map 

setType(String) 
getType(): String 
setProperty(String, Object) 
getProperty(String): Object 


M also khow that of ouy 
otk\r -fcatu\rcs dcpChd Oh -this 

dlass, so that makes i-t av\ eve^ 

bett 饮 dahdidatc h> stav-t with. 


「雜以 ， - 

If you decided to go with use case driven development, 
what would you start working on first? 
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analyze your features 


Analysis of a feature 

Once you’ve decided on a feature to start with, you’ve got 
to do some more analysis. Let’s start with what we had 
written down on the feature list: 


S. The framework supports multiple types of 
troops or units that arc game-specific. 

We also have the start of a class diagram, from Chapter 7: 


what wc ; vc got so -fav-... 
but this is still a fvetty 
3 ⑶饮 id dcsd\riptioh Jc what 
y\ttd -to dodc. 


Unit 

type: String 
properties: Map 

setType(String) 
getType()： String 
setProperty(String, Object) 
getProperty(String): Object 


TWis looks l*»kc -tV^c Wu — 七 
U a ^ood U^*t dass. So 


It looks like we’ve got everything we need to start coding, 
right? To help us make sure we haven’t forgotten anything, 
let’s go back to using some textual analysis. 

We don’t have a use case to analyze, but we can revisit 
the vision statement for Gary’s games, and see if we’re 
covering everything that Gary wanted his units to do. 


ttevVs vision 

y/ay katk m CV>a\>*tcv- ^>. 


Compare the class diagram for Unit with 
this vision statement. Are there things 
missing from our class diagram? 

What else might Gary expect to see when 
you say, “I’m done with writing code for 
the units in your framework?” 


Gary's Games - 

Vision Statement 

Gary s Ganies provides frameworks that game designers can us 
create turn-based strategy games. Unlike arcade-style shoot- ， em-up 
games and games that rely on audio and video features to engage the 
player, our games will focus on the technical details of strategy and 
tactics. Our framework provides the bookkeeping details to make 
building a particular game easy, while removing the burden of coding 
repetitive tasks from the game design. 

The game system framework (GSF) will provide the core of all of 
Gary’s Games. It will be delivered as a library of classes with a well- 
defined API that should be usable by all board game development 
project teams within the company. The framework will provide standard 
capabilities for: 

♦ Defining and representing a board configuration 

♦ Defining troops and configuring armies or other fighting units 

♦ Moving units on the board 

♦ Determining legal moves 

♦ Conducting battles 

♦ Providing unit information 

The GSF will simplify the task of developing a turn-based strategic 
board game so that the users of the GSF can devote their time to 
implementing the actual games. 
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iterating and testing 


Flcshiwg out the Uwit class 


In our class diagram, all we’ve really figured out is how to 
represent the properties of a unit. But in Gary’s vision statement, 
he’s expecting his game system framework to support a lot more 
than just those game-specific properties. 

Here are the things we came up with that Gary is expecting units 
in his framework to do: 


^ is ⑽叱 , because -the 

key-Fca-tuvc wc weve 4^usiha oh 
7 was 

WhrU— but just 
pv-opcvtics o( a Uhit. 


o Each unit should have properties，and dlass »s 

game designers can add new properties 七 favt> 6 ulav ok t t 

to unit types in their own games. dlass 


❾ 



七 uves avc 


Units have to be able to move from one 
tile on a board to another. 

Units can be grouped together into armies. 


/ou should have some ideas about 
how *to handle this -Pv-om ouv- 

赠 k elated key 

ba 乙 k ih Chap-tcv 7. 


all fulled 

s*ta 七 cmc 朽七 . 


Wow, great. Another list 
of things you re going to do. Look, 
I trust you and all, but I need to 
see something more than scraps 
of paper to believe your code is 
working. 


O 


^av-y is^-t satisfied v /狀 yo^r 
use ^ases dr\d lists... y/V^a*t do you 

七 Wk would make 知 Y bc,,cvc 

OY\ V/'llI 


Wat youVc v/ork'm^ 

sat'is-Py ^ ,s v-c^iv-cmc^-b? 
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customer demonstrations 


Showing off the Uwit class 

We worked on supporting game-specific units, and how 
to store the properties of a Unit, back in Chapter 7. 
But Gary wants more than a class diagram before he’s 
convinced you’re getting any work done. 


Unit properties 

U 

nit movement 

Unit groups 





Unit 

type: String 
properties: Map 

setType(String) 
getType(): String 
setProperty(String, Object) 
getProperty(String): Object 


Th.s may be what heed h> 

^ the WhiUk, but 

•tdocs h tdo {o p^ovc io 

•f 7 ihai y° u V / 50 j 础 ，此 


How about a test? Can’t you come 
up with a way to show me the unit has 
properties, and can move around, and that 
youVe got support for armies? I want to see 
your code actually running. 



Your customers want to 
see something that makes 
sense to them 

Your customers are used to seeing 
computer programs run on a computer. 
All those diagrams and lists may help 
you get on the same page with them in 
terms of requirements and what you’re 
supposed to build, but you’re going to 
need more than that before they think 
you’ve built anything useful. 

You need to come up with some test 
scenarios that you can show to your 
customer, which will prove that your 
code works, and that it behaves like 
your customer expects it to. 
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iterating and testing 


Writing test scenarios 

Test cases don’t have to be very complex; they just 
provide a way to show your customer that the 
functionality in your classes is working correctly. 

For the properties of a unit, we can start out with a 
simple test scenario that creates a new Unit, and adds a 
property to the unit. We could just show our customer a 
running program that displays output like this: 


Wic siav-b out by 
Crea 七 … 0 i 七 he 

u 

sc*t 

fv-ofcv-tics... - - 

valvA^s vaY 

w set. 


Be dav-c-ful... w sdc^av-io w is^*t 
same as u stcr\avio w vc been 
about m a use dasc stc^avio. 


ihe .ode youVe 

wv ' 七 h 3 ^Hy wo^ks. 


File Edit Window Help ItWorks 


% java UnitTester 
Testing the Unit class... 

••.Created a new unit 

• ••Set ' 、 type 〃 to ' 、 infantry 〃 

• • . Set 、 'hitPoints 〃 to 25 

• • .Getting unit type : ''infantry' 
••.Getting unit hitPoints : 25 


Test complete. 


svav*c "tV'C 


^ iic ou-tpui 

y° u ^a\ry -to 

ih 诎 cse bldhks. 


see 



BE tlie Customer 

WeVe already got one test 
scenario. It’S your job to 
play Gary, and ihink of two 
more test scenarios tiiat 


File Edit Window Help Scenario2 


% java UnitTester 
Testing the Unit class... 



Test complete. 


we can use to prove 
tiiat tire Unit class is 
wolfing like it should. 
Write tire output of each 
scenario in {ke code 
windows on {ke 


File Edit Window Help Scenario3 


% java UnitTester 
Testing the Unit class... 



Test complete. 
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exercise solutions 



BE Customer 

Solutions 

Your job was to tiling of 
two more test scenarios 
tiiat we can use to prove 
tiiat tire Unit class 
is wording like it 
should. Here are 
{ke two scenarios 
we came up witii: 


Unit properties 

U 

nit movement 

Unit groups 





File Edit Window Help ItWorks 


% java UnitTester 
Testing the Unit class... 

••.Created a new unit 

• ••Set ' 、 type 〃 to 、 'infantry 〃 

• ••Set ' 、 hitPoints 〃 to 25 

...Getting unit type : 、 'infantry 〃 
...Getting unit hitPoints : 25 

Test complete. 


s -the i C si 
s^Chav-io, -icsts 
scttihj ahd jettihg 
P^ropcirty values. 


Scenario ^Z: Changing property values 

We decided to test setting, and then changing, the value of 
a property. If the hitPoints property is set, for example, 
and then set again, getting the value of hitPoints should 
return the most recent value for that property: 


\)\j a ir\CV/ 

Uv\rt, so v/C 

•(jVmy out 


/ 


T?' 15 /I s 广 C 七切 sirnilav-— | 00 |^j h Q ^ 

说 — above, but it 

US jT ^,f9 ,h 9 a popdy value, 
thahjust scUih 3 ahd 
v*ctHcvihj a prope\rty. 


sc*t 

value WrtPo … "ts ， 

ar\d *bV^cr\ reset »*t 
{p a yveva value- 


File Edit Window Help Scenario2 


% java UnitTester 
Testing the Unit class... 
...Cv-ca*tcd 3 hcv/ uhi 七 


%i*tPom*U w *to 


… Se 七 'VrtPo 


his ： 1*5 




Finally, wc make 
suve Ki-tPoihts has 
the mos-t duv-v-chi 
v dluc, dhd hot the 
叫 mal value of l 1 ?. 


Test complete. 
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iterating and testing 


Scenario ^3: Getting now-existent property values 


For our third scenario, we decided to test what would happen when 
you tried to retrieve the value of a property that had never been set. 
Error conditions like this crop up all the time, and we don’t want our 
program crashing every time a game designer makes a small typo or 
mistake in their code. Here’s what we did to test this: 


TWis itsi sV^ov/s i\\t tusWcv- 


youVc y\o*t 

youv-c about 

•to deal y/itv^ uses tVic so^tv/arc 
av-c ou*ts'idic <^f *tV^c norm. 



S-tav-t out by dvcatihg ^jj^Edi^Windo^Hel^Scenano3 
a hew Whit 





sc*t a 

Ki*tPo'm*b pvopcvty, 

y^i\\\CM is *tKc r\oV-w»al 

Uru*t usa^c- 

(v(oy/ 1 c 七、 七 ” av>d 
addess a ^trbj 
七 ha 七 has 灼 0 v ^ uC * 


pmally, make suve ■ 

IX 灼 •七 s 七 “1 bc^3vcs 
>whcr> you ask ov a 
fvofc\rty *tV>a 七 docs 
have a value. 


% java UnitTester 
Testing the Unit class... 
...Cv-C 3 *tcd 3 K>cv/ uhi 


7 




Test complete. 


You skoulct test your software lor every 
ossible usa^e you can tkink oL Be creative! 

一 ■ O" J — — 

Don’t lorget to test lor incorrect usage ol 
tlie software ， too. You’ll catck errors earl 
anct make your customers very kappy. 
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questions on testing 



Unit properties 

U 

nit movement 

Unit groups 





We don’t have any code 
written yet. Aren’t we doing things a 


bit backwards by worrying about tests 
right now? 


A! Not at all. In fact, if you know what 
tests you’re going to use before you write 
your code, it's easy to figure out what 
code you’re going to need to pass those 
tests. With the three test scenarios we 
just developed, it should be pretty simple 
to write the Unit class, and the tests tell 
us exactly how our code should behave. 


Isn’t this just test driven 
development? 




Why are the tests so simple? I 
expected something a little fancier. 


You want to keep your tests 
simple, and have them test just a small 
piece of functionality at a time. If you start 
testing multiple things at once, it's hard to 
tell what might have caused a particular 
test to fail. You may need a lot more tests, 
but keep each one focused on a very 
specific piece of functionality. 




And each test makes sure 


a single method in the class works 
correctly, right? 


For the most part, yes. Formally, 
test driven development focuses on 
automated tests, and usually involves a 
testing framework like JUnit. But the idea 
of writing test cases, and then writing the 
code that will pass the test, is the core 
idea behind test driven development. 


So are we using test driven 
development or feature driven 
development? I’m confused... 


No, each test really focuses 
on a single piece of functionality. That 
might involve one method, or several 


methods. For example, you can’t test 
setting a property's value (which uses 
setProperty ()) without getting 
that property’s value as well (using 
getProperty ()). So it s one piece 
of functionality—setting a property—but 


it takes two methods. 


Can you explain why you tested 
getting a property that you didn’t set? 
Isn’t that testing the wrong way to use 
the Unit class? 


Testing incorrect usage of your 
software is usually at least as important 
as testing it when it’s used properly. 
Game designers could easily mistype 


a property name, or write code that 
expects some other piece of a game to 
set a property and asks for a property 


that doesn’t exist. It’s your job to know 
what will happen in these situations. 


Now that we’ve got our tests 
planned out, we can finally start coding 
the Unit class, right? 


A! Well, there's one more bit of 
design we need to think about first... 


A! Both. In fact, most good software 
analysis and design mixes lots of different 
approaches. You might start with a use 
case (use case driven development), 
and then choose just a small feature 
in that use case to start working on 
(which is really a form of feature driven 
development). Finally, you might use 
tests to figure out how to implement that 
feature (feature driven development). 


Test ctriven ctevelopment 
focuses on getting tke tekavior 
ol your classes riglit. 
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O 


O 


Guys, I’ve been looking 
at our class diagram for Unit, 
and I’m not sure that this is the best 
way to handle things. I think our 
commonality analysis might have 
been a little off. 



c 


Joe: What do you mean? We figured out that all properties in a Unit 
have a name and a value. So we decided to use a Map to store them all. 

Frank: And game designers can add any new properties they want by 
just creating new property names, and sticking name/value pairs in the 
Map with the setPropertyQ method. 


Jill: Right. But then, we also added a type property, since all units will 
have a type. And that’s something common for all units... 

Joe ： Sure. See, we did do the commonality analysis right. 

Jill ： .but we also now know that units can be assembled into groups, 
like armies or fleets or whatever. So what happens if we have two units 
of the same type in the same group... how can we tell the difference 
between them? 


Frank: You think we need some sort of ID, don’t you? 


Unit 

type: String 
properties: Map 

setType(String) 
getType()： String 
setProperty(String, Object) 
getProperty(String): Object 


ttcrcs i\\t tlass diagram 

Jill, a^d 

Joe avc distussmj. 


Jill: Yeah, maybe. Or at least a name... but even then, you can’t really 
prevent duplication with a name property, can you? 


Joe: OK, but that still doesn’t mean we need to change our design. We 
can just add the ID property into our property Map. So we’ve got a 
nice, uniform way to access all those properties, using the getPropertyO 
method. 

Frank: He’s right, Jill. And since we encapsulate away the details about 
property names into the properties Map, we could even change from 
using an ID to a name, or something totally different, and code using 
the Unit class wouldn’t have to change much... you’d just need to use 
the new property name in getPropertyO- That’s a pretty slick design! 

Jill ： But what about commonality? If ID is really common to all types 
of Unit, shouldn’t it be moved out of the Map, sort of like we did with 
the type property? 

Joe: Whoa... encapsulation or commonality. That’s tough... it seems like 
we can’t do one without screwing up the other. 
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commonality revisited 


^harpen your pencil 


Refine your commonality analysis. 

Before we close the book on dealing with Unit properties, there are a few things you 
still need to think through. Below are several properties that different units might 
have, and two sheets of paper. Write down on the Commonality sheet the properties 
that you think all units, regardless of their type, would have; on the Variability sheet, 
write down properties you think only specific types of units might have. 


Potewtial Unit Properties 


you 
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YY\Cr\C 

bo apply 
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weapon 

allegiance 

gear 

type 

hitPoiwts 

wingspan 

lastName 

strength 

weight 

lahdSpeed 

id 

speed 

ihtelligehce 

experience 

grouhdSpeed 

stamina 

firstName 

weapons 

hunger 
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iterating and testing 


Now update the Unit class diagram. 

With the details from your revised commonality analysis on page 442, you (might) need 
to update the Unit class diagram, shown below. Make any changes that might improve the 
design of the Unit class below, and add notes to remind yourself what the purpose of any 
additions you’ve made are going to be used for. 


You tV-OSS OU-t 

ov w\od>^*Y 

add't'ov^ *to 
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type: String 
properties: Map 



Add 


properties y ou 

thihk UWii 
heeds hew. 


setType(String) 
getType(): String 
setProperty(String, Object) 
getProperty(String): Object 
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a matter of opinion 



arpen your pencil 

k answers 
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Refine your commonality analysis. 


On page 442, we showed you several properties that different units might have. 
Your job was to write down on the Commonality sheet the properties that you think 
all units, regardless of their type, would have; on the Variability sheet, you should 
have written down properties you think only specific types of units might have. 
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You may have a different idea 
about what makes a good game. 

You might have played different games 
than we have, and come up with different 
common properties. That’s OK — just focus on how 
and why you made your own decisions. We’re going to 
use our choices in the rest of the chapter, so you should 
be comfortable with how we made our choices, too. 
















iterating and testing 
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Questions 




I didn’t have anything on the 


Commonality list except for “type”. Where 
did I go wrong? 




But won’t different choices at 


least result in different code and design 
implementations? 


A! You didn’t go wrong at all. Analysis 
and design are all about making choices, 
and sometimes you’re going to make a 
different choice than another programmer. 
There’s nothing wrong with that, as long as 
you have good, well thought out reasons for 
the decision you made. 


Yes, they sure will. But OOA&D, 
and software development, aren’t about 
making a particular decision, since many 
times there isn’t an exactly “right” or exactly 
“wrong” choice. They’re about writing well- 
designed software, and that can happen in 
a lot of different ways. 


In fact, even if two programmers made 
the same decision about commonality and 
variability in this exercise, it can lead to 
totally different design decisions when it 
comes to actually writing your classes. 

Let’s assume for a moment that two 
developers both came up with the answers 
for commonality and variability shown here, 
and then tried to revise the Unit class to 
reflect what they figured out... 
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solution #1: focus on commonality 


Solution # 1: 

Emphasizing Commonality 
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I pulled the properties that 
were common to all units into their 
own variables and methods, and then 
left the properties that varied in the 
properties Map. 


V\fe wet Saw badk m 

doov 

/\/lav-'»a 


Unit 

type: String 
properties: Map 

id: mi 
name: String < 


weapons: Weapon 
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sctNamc(Striwg) ^ 
getNameO; String 
addWeapon(Weapon ) ， 
getWeaponsO: Weapon 
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setType(String) 
getType(): String 
setProperty(String, Object) 
getProperty(String): Object 

getldO; int <= —— 


Sa 你 -figured that id 
would gc-t sti *m the Uhit 

匕 OhS*brudjo\r, so 灼 o t\ttA 

*fo\r a scildO method- 
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In this solution, all game designers can directly access the 
id, name, and weapons properties, instead of having to 
use getProperty () and work through the more generic 
properties Map. 

The emphasis is on keeping the common properties of 

a Unit outside of the properties Map, and leaving 
properties that vary inside the properties Map. 
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iterating and testing 


You defintely found some 
commonality between different unit 
types, but what about good encapsulation? 
That Unit class doesn’t seem very 
resistant to change, if you ask me. 


0 


Pesign decisions are always a tradeoff 

Sam chose to emphasize the things that are common 
across all types of Units. But there are some negatives 
to Sam’s design, too: 


We’re repeating ourselves 


mi\ 


T 


■Now there are two different ways 
I to access properties: through the 
Igetld (), getName (), and 
property-specific methods, and the 
g^Property () method. Two ways 
to access properties is almost certainly going to 
mean duplicate code somewhere. 



you sec 

potential -fov dupkate 
code, you’ll aUos*t always 

issues, 3s v/cll- 


Maintenance is a problem 

Now you’ve got property names| 
like id and name, hard¬ 
coded into the Unit class. 

If a game designer doesn’t 
want to use those, or wants to 
change them, it’s going to be a 
real hassle, and require changes to the Unit class. 
This is usually where encapsulation would help, 
and that leads us to Randy’s design choice... 




/ y ! 
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solution #2: encapsulate everything 


Solution 

Emphasizing Encapsulation 
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I encapsulated all the 
properties of every kind of Unit 
into the properties Map. My class 
is extremely resistant to change 



now. 


Unit 


4ype? String 
properties: Map 


■s&t-Typo(String) 

gctTypcO! Str in g 
setProperty(String, Object) 
getProperty(String): Object 


R;hdy didh’i add 
ah y p<ropc^-ti C s 
methods, ahd 
9 o-t Hd 

type liable a^d 
仏 e gc-tTypcO 
method ； ry«ovih0 
fat p^ropeirty i h *to 
the pv-opc\rtics /VJap. 


This solution focuses on encapsulating all the properties for a Unit 
into the properties Map, and providing a standard interface —— the 
getProperty () method —— for accessing all properties. Even 
properties that apply to all units, like type and id, are accessed 
through the properties Map in this solution. 

The emphasis is on encaysulation, and a flexible design. Even if 
the names of common properties change, the Unit class can stay the 
same, since no property names are hardcoded into the class itself. 
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But you re totally ignoring whafs 
common across Units. And how are 
game designers going to know that we 
intended name, type, id, and weapons 
to be standard properties? 


0 


Tradeoffs with this decision, too... 

Randy’s solution is more resistant to changes, and uses a lot 
more encapsulation, but there are tradeoffs with this design, 
as well. Here are a few of the downsides to Randy’s design: 




e’re ignoring commonality 

andy encapsulated all of the 
roperties into the properties 
ap, but now there’s nothing to 
dicate that type, name, id, and 
weapons are intended to be properties 


common to all Unit types. 



Lots of work at runtime 

getProperty () returns an Object, 

and you’re going to have to cast that 
into the right value type for each 
different property, all at runtime. That’s 
a lot of casting, and a lot of extra work 
that your code has to do at runtime, 
even for the properties that are commor 
to all Unit types. 



「槪 ： - 

Which developer’s solution do you think is best? Are there 
times where you think one solution might be the best choice, 
and other times where the other might work better? 
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you have to make a choice 

Let's go with the 
commonality-focused solution 

For Gary’s game system framework, let’s use Sam’s solution, 
which pulls the common properties of a Unit out into 
their own properties and methods, and leaves unit-specific 
properties in a separate Map. 
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Unit 

type: String 
id:int 

name: String 
weapons: Weapon [*] 
properties: Map 

setType(String) 
getType(): String 
getld(): int 
setName(String) 
getNamej): String 
addWeapon(Weapon) 
getWeapons(): Weapon [*] 
setProperty(String, Object) 
getProperty(String): Object 
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Questions 


I thought the other design, that focused on 
encapsulation, was better. Is that OK? 

Absolutely. Both design choices have 
positives, and either one might work well. The only 
thing you cannot do is be unwilling to change your 
design—whichever one you start with—if it turns out to 
not work well down the line. At each stage of iterating 
through your app, you need to reevaluate your design 
decisions, and make sure they’re still solid. 

So how do I know when I need to change 
my design? My code won’t just stop working, so 
what should I look out for? 

Iteration is really the key point here. Lots 
of design decisions look great at one stage of your 
development, but then turn out to be a problem as you 
get deeper into a particular part of your app. So once 
you make a decision, stick with it, and iterate deeper 
into your application. As long as your design is working, 
and you’re able to use good 00 principles and apply 
design patterns, you’re in good shape. If you start 
running into trouble with a decision, though, don’t ever 
be afraid to change designs and rework things. 




What happens when I can’t decide between 
a couple of good design choices? 

You always have to make a choice, even if 
you’re not 1 00% sure if it’s the right one. It’s always 
better to take your best guess, and see how things 
work out, rather than spend endless hours debating 
one choice or another. That’s called analysis 
paralysis, and it’s a sure way to not get anything done. 
It’s much better to start down one path, even if you’re 
not totally sure it’s the right one, and get some work 
done, than to not make a choice at all. 


Gooct software is tuilt 
iterativelyt Analyze ， 
design，anct tken 
iterate again, working 
on smaller and smaller 
parts ol your app. 


Eack time you iterate, 
reevaluate your design 
ctedsions，anct cton’t be 
airaict to CHANGE 
sometking il it makes 
sense lor your ctesign. 
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connecting code and tests 


Match your tests to your design 

We’ve got test scenarios we want to show Gary, and a desigi 
for the Unit class. The last thing we need to do before 
coding is to make sure our design for Unit will allow us to 
code a solution that passes all the tests. 
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Unit 

type: String 
id: int 

name: String 
weapons: Weapon [*] 
properties: Map 

setType(String) 
getType(): String 
getld(): int 
setName(String) 
getName ()： String 
addWeapon(Weapon) 
getWeapons(): Weapon [*] 
setProperty(String, Object) 
getProperty(String): Object 


Test 
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File Edit Window Help It Works 


% java UnitTester 
Testing the Unit class... 

••.Created a new unit 
• ••Set type to 、 'infantry 〃 

... Set hitPoints to 25 
...Getting unit type : ''infantry' 
...Getting unit hitPoints : 25 


t 泣 ::: 


File Edit Window Help Scenario2 


% java UnitTester 
Testing the Unit class.•• 

•..Created a new unit 
... Set hitPoints to 25 
... Set hitPoints to 15 
...Getting unit hitPoints : 15 


File Edit Window Help Scenario3 



S 々W 0 . 


Fo\r -this v/C jus*t Y\ttd *to ^dll 
3C*tPvopc\r*ty( 、七代灼咖 /’ ) ， wi*thou*t 
cvc\r setting u s*t\rc^^*th W pv-opc\rty, 
by\A sec >/ha*t happens. 
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Test compl % java UnitTester 

Testing the Unit class... 

••.Created a new unit 
•••Set hitPoints to 25 
••.Getting unit strength: [no value] 
...Getting unit hitPoints : 25 


Test complete. 
















iterating and testing 


Let's write the Unit class 

It’s been two chapters in coming, but we’re finally ready to 
write the code for the Unit class. Here’s how we did it: 

package headfirst. gsf . unit; 



Unit.java 


public class Unit { 
private String type; 
private int id; 
private String name; 
private List weapons; 
private Map properties; 


£. - 

public Unit(int id) { 
this.id = id; 


lAfe lake 仏 c IP d 七 
•m 七 W 吵如 tcmsWW" 


public int getld() 
return id; 



•so wc ohly heed a gctldO, 
and y\oi a scildO as well. 


} list code 

^esc Siw»flc ^C*t*tcv*S 3^(1 

// getName () and setName () methods srttevs "to save a little spate. 

// qetType() and setType() methods ^ 

WlUeed “一 ^ 

' tlass -to ^akc tW«s todt 





public void addWeapon^eapon^weapon) 
if (weapons == null) { 

weapons = new LinkedList(); 

} 

weapons.add(weapon); 


public List getWeapons() 
return weapons; 

} 


savcs ^ liiile bii Jf 1 T ^ { 
cs P^lly ^ 

^Js oj ^ 


Wc seated 
〒 切 \A/ca\>o^ \ava, 


cw 

wC 


public void setProperty(String property, 
if (properties == null) { 

properties = new HashMap(); ^ 

} 

properties•put(property, value); 


Object value) 


M cdcd . 


public Object getProperty(String property) { 


if (properties == null) 
return null; 



return properties.get(property); 





t 
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test cases examined 



Test cases dissected. 
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We’ve talked a lot about test cases, but so far, 
you haven’t seen how to actually write one. 
Let’s examine a test case up close，and see 
exactly what makes up a good test. 


o 

o 


Each test case should have an ID and a name. 

The names of your test cases should describe what is being tested. 
Test names with nothing but a number at the end aren’t nearly as 
helpful as names like testProperty () or testCreation (). 

You should also use a numeric ID, so you can easily list your tests 
cases out (something we’ll do on the next page). 

Each test case should have one specific 
thinp that it tests. 

Each of your test cases should be atomic., each should test 
only one piece of functionality at time. This allows you 
to isolate exactly what piece of functionality might not be 
working in your application. 


ho-t -to -to 

卜 as icsil, 
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Each test case should have an input you 、 〜 

supply. 

You’re going to give the test case a value, or a set of values, 
that it uses as the test data. This data is usually then used to 
execute some specific piece of functionality or behavior. 


|.f ^ouVc WrbP“*ts 

佔 C 70U su ?? l7 ^ V ouV 

itsi 6asc. 



Each test case should have an output 
that you expect. 

Given your input, what should the program, class, or 
method output? You’ll compare the actual output of the 
program with your expected output, and if they match, 
then you’ve got a successful test, and your software works. 




i-P 


you 
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Most test cases have a starting state. 

Do you need to open a database connection, or create a 
certain object, or set some values before running your test? 
If so, that’s all part of the starting state of the test case, and 
needs to be handled before you run the actual test. 


Thcv-c^s ^o*t rn\At\\ 

state -fov- -the W 灼 i 七 dass. Wlc 

do Y\ttd *to ^\rca*tc d 
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arpen your pencil 

Design your test cases. 


Below is a table with 5 columns, one for each of the 5 important parts of a test 
case. Your job is to fill in the table with information for the test cases we’ve 
laid out in this chapter already. We’ve even done the first one to help get you 
started, and filled in a few empty spots on the rest of the tests. 

This test sets the 


* nis test sets the '"type” pv-opevtv 
"to 3 value o-p 
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File Edit Window Help ItWorks 


% java UnitTester 
Testing the Unit class.•• 

••.Created a new unit 
• ••Set type to 、、 infantry 〃 

•••Set hitPoints to 25 
...Getting unit type : ''in fan try ; 
...Getting unit hitPoints : 25 


Test complete. 


File Edit Window Help Scenario2 


% java UnitTester 
Testing the Unit class... 

••.Created a new unit 
••.Set hitPoints to 25 
... Set hitPoints to 15 
••.Getting unit hitPoints : 


File Edit Window Help Scenario3 


% java UnitTester 
Testing the Unit class... 

••.Created a new unit 
•••Set hitPoints to 25 
••.Getting unit strength: [no value] 
...Getting unit hitPoints : 25 




Test complete. 
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i^harpen your pencil 

、 answers Design your test cases. 

Below is a table with 5 columns, one for each of the 5 important parts of 
a test case. Your job was to fill in the table with information for the test 
cases we’ve laid out in this chapter already. 
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Questions 


How did our three test scenarios turn into four test cases? 


And all these tests will let us know that our software works 
like it should, right? 


Because the first test case really tested two things: setting and 
retrieving a common property, which has its own variable and access 
method (like getType ()), and setting a retrieving a unit- or game- 
specific property, which is accessed through getProperty () (like 
hitPoints). That’s two pieces of functionality, so two different test 
cases are required. 


A! It’s a good start on that, yes, but remember, we started out 
writing the tests so that we could prove to the customer that the 
software we’ve been writing actually will work. Our test cases let the 
customer see some code actually running, as well as help us find bugs 
in our code before we get too far along in our development cycle. 
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T est Puzzle 

Now that you know what test cases are, and have several written up in table form, 
you’re ready to code a test class to show your customer that your software works, 
and prove to yourself that there aren’t any bugs in the code that you’ve written. 

The problem: 

Gary wants to know that you’re making progress on supporting 
units in his game system framework, and you want to be sure that 
the code you’ve written for Unit. java works properly. 

Your task: 

o Create a new class called UnitTester. java, and import the Unit 
class and any related classes into it. 

Add a new method for each test case you figured out from the table on 
page 456. Be sure to use descriptive names for the test methods. 

❺ Each test method should take in an instance of Unit with any starting 
state already set, and any other parameters you think you’ll need to run 
the test and compare an input value with an expected output value. 

o The test method should set the supplied property name and property value 
on the provided Unit, and then retrieve the expected output property 
value using the expected output property name. 

❺ If the provided input value and expected output value match, the method 
should print out “Test passed ”； if they don’t match, the method should 
print “Test failed”，along with the mismatched values. 

o Write a main () method that sets up the starting state for each test, and 
then runs each test. 

Bonus Credit: 

o There are several things in Unit. java that are not being tested by the 
scenarios on page 456. Identify what each of these are, and create a test 
method for each. 

❾ Run these tests from your main () method as well. 
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Test Puzzle Solutions 


public class UnitTester 


Hcirc s "the djdSS y/C WV'O'tc "to 

test the Uhit dlass. 




r 


public void testType(Unit unit. String type. String expectedOutputType) 
System. out. print In (''\nTe sting setting/getting the type property .’’）； 
unit.setType(type); 

String outputType = unit.getType() 

if (expectedOutputType.equals(outputType)) 

System, out.println (''Test passed ”）； 

} else { 

System. out. println (''Test failed : ’’ + outputType 
expectedOutputType); 

P^opcir-tics s-tov-cd 


Most *bcs*b tv\d 七 a 

£.ompavisoir\ O-f *tV^C 

OU'tf'A't output 


didn't match 


output values. 


taA *tcs 七 
wc*t^od 
diWcvcyrt 

tac\\ wc-tV^od 
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Uyv\-t tlass. 

^public void testUnitSpecificProperty(Unit unit. String propertyName, 

Object inputValue, Object expectedOutputValue) { 

System. out. println (''\nTe sting setting/getting a unit-specific property .’’）； 
unit•setProperty(propertyName, inputValue); 

Object outputValue = unit.getProperty(propertyName); 
if (expectedOutputValue.equals(outputValue)) { 

System, out .println (''Test passed ”）； 

} else { 

System. out. println (''Test failed : ’’ + outputValue +、' didn't match ” + 
expectedOutputValue); 
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public void testChangeProperty (Unit unit. String propertyName , 

Object inputValue, Object expectedOutputValue) { 

System. out. println (''\nTe sting changing an existing property's value .’’）； 
unit•setProperty(propertyName, inputValue); 

Object outputValue = unit.getProperty(propertyName); 
if (expectedOutputValue.equals(outputValue)) { 

System, out .println (''Test passed ”）； 
else { 

System. out. println (''Test failed : ” + outputValue +、' didn't match ” -f 
expectedOutputValue); 


class 


Unit- 
Tester 
test () 
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public void testNonExistentProperty(Unit unit. String propertyName) { 

System, out .print In (''\nTe sting getting a non-existent property's value .’’）； 
Object outputValue = unit.getProperty(propertyName); 
if (outputValue == null) { 

System, out .printIn (''Test passed ”）； 

} else { 


System. out. print In (''Test failed with value of 


outputValue); 
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public static void main(String args[]) { 

UnitTester tester = new UnitTester (); 

Unit unit = new Unit(1000); 

tester . testType (unit, ''infantry’’ ， ''infantry ’’）； 

tester. testUnitSpecificProperty (unit, 、 'hitPoints 〃， 

new Integer(25), new Integer(25)); 
tester. testChangeProperty (unit, 、 'hitPoints 〃， 

new Integer(15), new Integer(15)); 

tester . testNonExistentProperty (unit, ''strength"); 



And now for some bonus credit... 

We added three new test cases to our table, to handle the three 
properties common to all units that aren’t tested in UnitTester. You 
should be able to write three additional test methods based on this 
table. Did you figure these out on your own? 
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show the customer 


Prove yourself to the customer 

With a Unit class and a set of test cases, you’re ready to 
show Gary some working code, and prove that you’re on the 
right track to building his game system framework just the 
way he wants it. Let’s show him the test class running: 
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Ifs not perfect for me— I doiVt need your 
framework returning null all the time, and my guys 
having to check for it. We II write our code correctly, 
so if your framework gets asked for a property that 
doesn’t exist, just throw an exception, OK? 



Let’s change the programming 
contract for the game system 

When you’re writing software, you’re also 
creating a contract between that software and 
the people that use it. The contract details how 
the software will work when certain actions are 
taken —— like requesting a non-existent property 
on a unit. 

If the customer wants an action to result in 
different behavior, then you’re changing the 
contract. So if Gary’s framework should throw 
an exception when a non-existent property 
is queried, that’s fine; it just means that the 
contract between game designers and the 
framework has changed. 



Wken you program hy contract, 
ym anct your software’s users are 
agreeing tlrat your software will 
Lekave in a certain way . 、 

*to move about 

诎 at tW,s mca 衫？ 丁心七 
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programming by contract 

WcVc been programming by 
contract so far 

You probably didn’t notice, but we’ve been doing 
something called programming by contract in the 

Unit class so far. In the Unit class, if someone asks for a 
property that doesn’t exist, we’ve just returned null. We’ve 
been doing the same thing in getWeapons (); if the 
weapons list isn’t initialized, we just return null there, too: 
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This is the contract for Uwit 

The Unit class assumes that people using it are 
competent programmers, and that they can handle null 
return values. So our contract states something like this: 


Hey, you look pretty smart. I’m gonna return null 
if you ask for properties or weapons that don't 
exist. You can handle the null values, OK? 
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Programming by contract is 
really all about trust 

When you return null, you’re trusting programmers to 
be able to deal with null return values. Programmers are 
basically saying that they’ve coded things well enough that 
they won’t ask for non-existent properties or weapons, so 
their code just doesn’t worry about getting null values back 
from the Unit class: 


Hey, you look pretty smart. I’m gonna return null 
if you ask for properties or weapons that don’t 
exist. You can handle the null values, OK? 


Look, we know what were doing. Our code will 
only ask you for properties that exist. So just 
return null... trust us to do the right thing, OK? 


And we can always change the 
contract if we need to... 

Back on page 461， we were asked to stop returning 
null, and throw an exception instead. This really isn’t a 
big change to the contract; it just means that now game 
designers are going to have big problems if they ask for 
non-existent properties or weapons. 

You know what? Were really confident were not 
going to ask you for non-existent properties. In 
fact, if we do, just throw an exception, and it will 
crash the program, and we'll hunt down the bug. 
Trust us... throwing an exception is no problem. 


Sure. As long as you know I’m going to start throwing 
an Exception, weVe good to go. I’ll just change my 
code, and we'll start using this new contract. 
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defensive programming 


Put if you don't trust your users... 

But what happens if you don’t think your code will be used correctly? 
Or if you think that certain actions are such a bad idea that you don’t 
want to let users deal with them in their own way? In these cases, you 
may want to consider defensive programming. 

Suppose you were really worried that game designers using the 
Unit class, and asking for non-existent properties, were getting 
null values and not handling them properly. You might rewrite the 
getProperty () method like this: 
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public Object getProperty(String property) 

throws IllegalAccessException { 


if (properties 


null) 
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dedl 

^■。产矿 七 Y . 




throw new IllegalAccessException( 

''What are you doing? No properties !”)； 

■return properties . get (pi-cjpci-ty); 

Object value = properties.get(property); 

if (value == null) { 

throw new IllegalAccessException( 

''You're screwing up! No property value.") 

else { 

return value; 


cavi 

fBC^£D 

cxdcp-tioh, so todt usihg 

will have io caich 
this cx^eptioh. 


class 
Unit { 
Unit () {J 


This is ^ derive 


Unit.javc 



I'm sure you're great code and all, but I just don't 
trust you. I could send you null, and you could 
totally blow up. So let's just be safe, and I’ll send 
you a checked exception that you’ll have to catch, 
to make sure you don't get a null value back and do 
something stupid with it. 
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or if they don't trust you. 


Of course, when programmers use your code, they might not 
trust you either... they can program defensively as well. What if 
they don’t believe that you’ll only return non-null values from 
getProperty () ? Then they’re going to protect their code, 
and use defensive programming, as well: 


Hcvcs a sample o-f 
UUvt tlass. 



// Some method goes out and gets a unit 
Unit unit = getUnit(); 


TW»s codt dots 
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// Now let's use the unit... 

String name = unit.getName(); 

if ((name != null) && (name.length() > 0 )) { 

System. out. print In (''Unit name : " + name); 

Object value = unit. getProperty (''hitPoints^) 

if (value != null) { 

try { 

Integer hitPoints = (工 nteger)value; 

[catch (ClassCastException e) { 

// Handle the potential error 


"This todc is 
WV-i-ttch CjtjrCmdy 
dc-Pchsivdy. 


// etc... 


Projratntnitt^ 


ther, are no . 

Dumb Questions 


You said on page 463 that we could change the contract 
to throw an exception, but then you said here that throwing an 
exception is defensive programming. I’m confused... 

A! It’s really not that important what kind of exception is 
thrown. What’s important is how your customers and clients are 
involved in that decision. In programming by contract, you work 
with the client to agree on how you’re going to handle problems; 
in defensive programming, you make that decision in a way that 
ensures your code doesn’t crash, regardless of what the client 
wants to have happen. 


When we decided to switch from returning null to throwing an 
exception, we did that by listening to the client, and agreeing on 
that particular action as a response to a request for non-existent 
properties. And we made the exception a RuntimeException, 
again because the client didn’t want to add lots of try/catch 
blocks to their code. They could have just as easily asked for a 
checked exception, and we could have agreed—and still been 
programming by contract. 

Compare that to defensive programming, where we’re not really that 
interested in what the client wants. In defensive programming, we're 
making sure that we aren’t responsible for crashing a program, 
and we even go out of our way to try and prevent the client from 
crashing their program. 
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fireside chat: protect the programmer? 


Fireside Ghats 



Tonight’s talk： Programming by Contract and Defensive 
Programming duke it out over trust issues with programmers. 


Programming by Contract 


Defensive Programming 


It’s nice to sit down with you and meet face to face, 
we really don’t see each other like this very often. 


Yeah, I really don’t like to get out much. 

There’s just so much that can go wrong. 

What do you mean? 

Well, I could be crossing the street, and slip on 
some Banana.peelO that hadn’t been garbage 
collected, or some for loop without a good 
termination condition could come screaming 
through the intersection... there’s a lot of bad 
code out there, you know? 

Well, sure, I guess... but you can’t live your whole 
life in fear of bad code. At some point, you have 
to just commit to how you’re going to behave, and 
trust other programmers to use you right. 

Are you kidding me? Have you met most of the 
programmers writing the code you’re talking 
about trusting? They’re too busy watching 
Lost to worry about checking for bugs in their 
software. If they’d stop gawking at that Kate 
and her freckles, maybe I wouldn’t have to 
double-check their work so much. 


Boy, it sounds like you have trust issues. 


And you don’t? 

No. I trust programmers understand the contract 
that I provide them. 

Contract? Oh, you still think that if you 
explain what you’ll do in a certain situation, 
that a “good” programmer will use you 
correctly? Boy, what naivete! 
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Programming by Contract 


Defensive Programming 


Look, my contract explicitly states what I have to do, 
and what people that use me have to do. 


Look, if programmers and users don’t keep their end 
of the bargain, I can’t be held responsible for that. If 
they violate the contract, they deserve what they get. 

I can’t be held liable. 


With tons of extra code, little “if (value == null)” 
checks everywhere? What a beating. Sounds like you 
slow things down more than anything. 


Superman? You did nof just say that 


But that’s the point! I may not be great for lazy 
programmers, but I’m terrific for programmers who 
do check their work. They get a performance bump, 
and their code is shorter when they use me. 


And that’s what I provide, just without all the trust 
issues and baggage you bring along... 

I’ll show you safe code, you little... 


Haven’t you heard? Over 50% of contracts 
today end in divorce... or maybe that was a 
different stat, I’m not sure... anyway, do you 
really think programmers are paying attention 
to your little contract? 


Sounds pretty callous to me. I try and help my 
users, and even protect them from themselves. 


Sure, sometimes I’m not the best performer, but 
I sure keep everyone safe from disaster. I often 
like to think of myself... a bit like Superman. 

It’s true! Besides, how many times has your 
code gone up in smoke because of a lazy 
programmer who ignored your contract? 


Short code, humph. I’d much rather have good 
code. Code that keeps programmers and users 
safe. 


Hey, I’ve got a trust issue for you right here... 


... transmission ended … Veuillez nous aider! … 4 8 15 ... 
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identify the technique 



Feature Driven Development, Use Case Driven Development, 
Programming by Contract, and Defensive Programming have 
all showed up for a masquerade party, but none of them bothered to 
wear name tags. They’re all a chatty bunch, though, so it’s up to you 
to listen to what they’re saying, and try and figure out who’s behind 
the masks. Be careful.... sometimes more than one masked guest 
could be saying the same thing. 


I’m very well-ordered. I prefer to take 
things one step at a time, until I’ve 
made it from start to finish. 


TveH^ure^HFsai™he would call ， 
but how can you really believe 
anyone anymore? 


Oh, absolutely，requirements really 
get me motivated. 

I’m very well-behaved. In fact, I’ve been 
focusing on all of my own behavior 
before moving on to anything else. 

Really ， it’s all about my customer. I 
just want to satisfy them, after all. 

Hey, you’re a big boy. You can deal 
with that on your own... it’s really not 
my problem anymore, is it? 


As long as you’re good with it，so 
am I. Who am I to tell you what to do, 
so long as you know what you can 
expect from me. 
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iharpen your pencil 


Change the programming contract for Unit. 

Gary’s clients want Unit to assume they’re using it correctly. That means 
that if a non-existent property is being queried, then something has truly 
gone wrong in the game, and an exception needs to be thrown. Your job 
is to: 

1. Update Unit.java so that requests for a non-existent property result in 

an exception being thrown. Figuring out the type of exception to use 
is up to you. 

2. Update UnitTester and the test cases that this contract change affects 

to reflect this new contract. 


3. Re-run UnitTester and make sure Unit.java still passes all of the tests. 



Ouv avc or\ fay. 
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Unit properties 
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t^harpen your pencil 

answers 


Change the programming contract for Unit. 

Gary’s clients want Unit to assume they’re using it correctly. That means 
that if a non-existent property is being queried, then something has truly 
gone wrong in the game, and an exception needs to be thrown. 
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public Object getProperty(String property) 
if (properties == null) { 

return ni>^l / ■ 

throw new RuntimeException( 

''No properties for this Unit."); 


XCtUIrn p~r^>p^T~h i ^ q rjo-h {p^op0]f r~ 

Object value = properties.get(property); 
if (value == null) { 

throw new RuntimeException( 

''Request for non-existent property."); 
} else { 

return value; 
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Questions 


Why are you throwing a RuntimeException, and not a 
checked exception, like HlegalAccessException? 

If you used a checked exception, code that calls 
getProperty () would have to check for that exception, in 
try/catch blocks. That’s not what the client wanted; we agreed 
to a contract that would let them code without having to catch for 
any exceptions. So by using a RuntimeException, no extra 
worked is required for their client code to use the Unit class. 


What about the get methods for other properties, like 
weapons, name, and id? 


A: id and name are an int and string, respectively, so 
those aren’t a problem (id is required to create a new Unit, and 
name will either be null or a string with a value). The weapons 
property is a List, so if you call getWeapons () when there 
aren’t any it’s going to result in a null list being returned. You could 
change that method to throw an exception if the weapons list was 
empty, although that wasn’t specifically asked for by the clients. 
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Wken you are programming Ly contract, you’re working witk client 
cocte to agree on liow you’ll lianctle problem situations. 

Wken you’re programming ctefensivelv, you’re making sure tke client 
gets a ” safe” response, no matter wkat tke client wants to kave ltappen. 
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public void test4(Unit unit. String propertyName) { 

System.out.println( 

、'\nTesting getting a non-existent property's value .’’）； 

try { 

Object outputValue = unit.getProperty(propertyName); 

} catch (RuntimeException e) { 

System, out .println (''Test passed ’’）； 

return; 

} 

System, out.println (''Test failed. 〃）； 

class 
Unit- I 
Tester {1 
test() {fj 
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UnitTester.java 
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You said that programming by contract resulted in less 


code, but it seems like we just added a lot of code to Unit.java. 


I still don’t see why we’re switching to programming by 
contract here. Why is it so much better? 


A! That’s because instead of directly returning null, we throw 
a new RuntimeException. But that’s more of a special case 
here than the rule. Most of the time, you’ll not have much extra 
code on the service side, because you’re simply returning objects 
and values without checking to see if they’re non-null, or within a 
particular data range. 


It’s not a matter of being better or worse; it’s a matter of 
what your customer wants. In fact, you’ll rarely decide on your 
own if you want to do programming by contract or defensive 
programming. That’s something that’s usually determined by what 
your customer wants, and the types of users that will be using the 
software that you’re writing. 
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testing the new contract 

Moving units 

We’ve finally finished up unit properties, and can 
move on to the next item on our list: 



1 七 "fcook B while, but y/cVc 

-Pihally Oh -to the hext piede 

-Puh^-tiohality m -the Uhi-t dass. 


Each unit should have properties, and 
game designers can add new properties 
to unit types in their own games. 


^/cVc ov\ "to 
dcalm ^ …狀 
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Units have to be able to move from one 
tile on a board to another. 

Units can be grouped together into armies. 


Haven't we been here before? 


This should sound pretty familiar... we already dealt 
with movement in Chapter 7: 
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Prcak your apps up into smaller 
chunks of fuwctiowality 

We’ve been talking a lot about iterating deeper into your 
application, and at each stage, doing more analysis and 
design. So you’re taking each problem, and then breaking it 
up (either into use cases or features), and then solving a part 
of the problem, over and over. This is what we’ve been doing 
in this chapter: taking a single feature, and working on that 
feature until it’s complete. 





Put you caw still break things up further... 

But once you choose a single feature or use case, you can 
usually break that feature up into even smaller pieces of 
behavior. For example, a unit has properties and we have 
to deal with unit movement. And we also need to support 
groupings of units. So each of these individual pieces of 
behavior has to be dealt with. 

Just like when you broke your app up and began to iterate, 
you’ll have to do more analysis and design at each step. 
Always make sure your earlier decisions make sense, and 
change or rework those decisions if they don’t. 
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Your decisions can iterate down, too 

Lots of times you’ll find that decisions you made earlier save 
you work down the line. In Gary’s system, we decided that 
game designers would deal with movement on their own. So 
now that we’re talking about how to handle unit movement, 
we can take that decision we made earlier, and apply it here. 
Since it still seems sensible — there’s no reason to change that 
decision — we can have game designers worry about handling 
unit movement, and move on to the next piece of behavior. 
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iQl Units have to be able to move from one 
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grouping units is up to you 


Unit properties 


Unit movement 1 Unit groups 



Feature Puzzle 

By now, you should have feature driven development, iteration, 
analysis, and design down pretty solid. We’re going to leave it up 
to you to handle the last bit of behavior and finish off the Unit 
feature of Gary’s game system framework. 
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The problem: 

Gary’s framework needs to support groups of units. 

Your task: 

o Create a new class that can group units together, and both add and remove 
units to the group. 

❺ Fill out the table below with test case scenarios that will test your software, 
and prove to Gary that the grouping of units works. 

Add methods to UnitTester to implement the test scenarios in the table, 
and make sure all your tests pass. 



七 ha 七 

Youll use all 
vo>/s... oV" 七 V»a 七 

you >/o 於 ’ 七於 ccd 

wov-c V-OY/S. 



IP 

lVha*t wcVc 
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p BULLET POINTS - 

■ The first step in writing good software is to 
make sure your application works like the 
customer expects and wants it to. 

■ Customers don’t usually care about diagrams 
and lists; they want to see your software 
actually do something. 

■ Use case driven development focuses 
on one scenario in a use case in your 
application at a time. 

■ In use case driven development, you focus 
on a single scenario at a time, but you also 
usually code all the scenarios in a single 
use case before moving on to any other 
scenarios, in other use cases. 

■ Feature driven development allows you to 
code a complete feature before moving on to 
anything else. 

■ You can choose to work on either big or small 
features in feature-driven development, as 
long as you take each feature one at a time. 

■ Software development is always iterative. 

You look at the big picture, and then iterate 
down to smaller pieces of functionality. 

■ You have to do analysis and design at each 
step of your development cycle, including 
when you start working on a new feature or 
use case. 


■ Tests allow you to make sure your software 
doesn’t have any bugs, and let you prove to 
your customer that your software works. 

■ A good test case only tests one specific piece 
of functionality. 

■ Test cases may involve only one, or several, 
methods in a single class, or may involve 
multiple classes. 

■ Test driven development is based on the 
idea that you write your tests first, and 
then develop software that passes those 
tests. The result is fully functional, working 
software. 

■ Programming by contract assumes both 
sides in a transaction understand what 
actions generate what behavior, and will 
abide by that contract. 

■ Methods usually return null or unchecked 
exceptions when errors occur in 
programming by contract environments. 

■ Defensive programming looks for things to 
go wrong, and tests extensively to avoid 
problem situations. 

■ Methods usually return “empty” objects 
or throw checked exceptions in defensive 
programming environments. 
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finishing up the unit class 


Unit properties 


Unit movement 


Unit groups 



lAfe dctidcd *to use a 

s*bov-'>y\5 IP 

oi? a 七 as 七 he key’ 

av\d *tV^c Uy\\-t 

as value ok 

a 灼 cyrtv-y- 




Feature Puzzle Solutions 

Gary’s framework needs to support groups of units, and 
should also allow groups of those groups (in as many 
nestings as the game designer wants to allow). 


public class UnitGroup 
private Map units; 


Vou dveate a ^ W 

-to {\\t yro\A^ 

public UnitGroup(List unitList) { 

units = new HashMap(); 

for (Iterator i = unitList.iterator(); i.hasNext(); ) { 

Unit unit = (Unit) i . next () ; 

units . put (unit. getld () , unit) ; ^ - ^Ohstv-u^W jus-fc adds all the uh.rfcs 

i to its uhi-fcs 


to Its Uhits May, scUiha the key o*f 
從 h Ch-tiry h> ihe ID d ca^ Uhii 


By usm^ a yi/Iap 

o\ u»r>i-ts ; y/c da 灼 

<rct\ricvc ^Y\d 
remove uhits by 
theiv- ID, y/hidh 

is 3 hide bit 

•Pur^ticmality. 


public UnitGroup() { 

this(new LinkedList()); 

} 

public void addUnit(Unit unit) { 
units•put(unit•getld(), unit); 

} 

public void removeUnit(int id) { 
units.remove(id); 

} 

public void removeUnit(Unit unit) { 
removeUnit(unit.getld()); 

} 

public Unit getUnit(int id) { 
return (Unit)units.get(id); 

} 


rtcrcs tlass a»ayam U 

Jc d>d- 




UnitGroup 

units: Map 

addUnit(Unit) 
removeUnit(int) 
removeUnit(Unit) 
getUnit(int): Unit 
getUnits(): Unit [*] 


public List getUnits() { 

List unitList = new LinkedList(); 

for (Iterator i = units.entrySet() .iterator (); i.hasNext() 


Unit unit = (Unit)i.next() 
unitList.add(unit); 

} 

return unitList; 


Theve’s a little bit o( wov-k 
•m a lisi o( all uh’rts, 

smdc v/C s-fcov-c the uhiis m a 
bu*t wc thoujh-t i*t v/ds 

hav'mj units s-fcoved by ID- 
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And mow for the test cases: 


Wc s*tarted 如 IPs so 七 
y/ould^*t i\\t IPs o\ 

七 -test tascs v/c already have. 



IP 

lVha*t wcVc 

Ihfut 

Expected Ou*tpu*t 

Siav-tm^ S*ta*tc 

10 

-fvom d lis*t Uhi*ts 

Lis*t c^P 

u 灼 i*ts 

£dme lis*t o-f u 灼 i*U 

Mo c^istmg *ms*tah^c o-f 
Uhi*tqv-oup 

II 

Addmg d uni 七七 0 為 youp 

Whi 七 v/rth 

IP o? 100 

Whi 七 wi*th ID of 

loo 

IX 灼 i 七今 voup wi*th ho 
Ch*tv"ics 

IZ 

a uni*t by i*ts ID 

loo 

Whi 七 with ID of 

loo 

W 灼 i 七今 \roup wi*th ho 
Ch*tv"ics 

IZ 

all 七 he u 灼 i*b m a 
^\roup 

m 

Lis*t o-f u 灼 i*ts *tha 七 

mashes ih’rtial list 

U»r>i*t^\roup v/i*th d khovm 
lis*t o-P uhi*ts 

1 午 

Rcmovih<\ a uhi 七 by 七 he 

IP *thc u^i*c 

loo 

Lis*t o-P uhi*ts ^ohC 
wi*th IP o-f 100) 

W 灼 i 七与 voup wrth ho 

15 

Rcmovm^ a uhi 七 by 七 he 
U^it *ms*ta^dc 

Whi 七 v/rth 

IP o? 100 

Lis*t o-r uhiis (ir>ohC 
wi*th IP o-f 100) 

Uir>i*t^\roup wi*th v\o 

Ch*tvics ' 〆 



Wert a\rc the icsi tascs 
*Po\r Uhit^v-oup that wc 
up with. Did you 
tliihk o( Bv\y othevs? 


We like *to start v /狀 

make suv-c *tVic unrb w ve 
y/ovkm^ y/i*tV> doir\ "t 
appeav- m *tV^c Un»*t^v-oup. 



ONLINE 


You should be able to write the code for UnitTester using the test 
case table shown here. If you want to see how your code compares 
with ours, visit http://www.headfirstlabs.com, click on Head First 
OOA&D, and look for “UnitGroup Test Cases.” 
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Tools for your 00A 备 P Toolbox 

We learned about several approaches to 
iterating through your project, and even a bit 
about two common programming practices in this 
chapter. Add all these to your toolbox: 


Rw 


^aly sis a^d Vts\ 




6\ood V-C^UIV-CI 

Y/ov-ks like y°^ so-f-t>wa\rc is easy *to| 

wfc ⑶ d ， 


00 P\rihdiples 


Encapsulate y/ha 七 varies. 

Code -to ar\ v-athev* *thair» 

irwplcrwCh-ta*tio^. 

B-a^h dass m your application should have 
oy\c vcasoirv -to 

Class^^ u *' , 

YrditzxCts 

pv-o^V" 3 wwm^ by d>ov>"brd 6 *t se*ts 叶 a 於 

ayrtt^ty\i about Koy/ youv so 礼 wave 

behaves thal you a^d use" d Y ouV， 

so^-t>wa\rc aycc -to abide by. 

Pc-fcv^sWc Y^oyr^n\\v\^ doCSv\ t "trust 
0 从伙 so^ W, dots C%W.vc c^o^r 
a^d da-ta 乩 wu\re Ae oi\\tr 

so-fWc docs^-t yvc you bad ov Msale 


kc C 

Yol- so^l 


L-istch -to -the ahd -Pijuirc ou-t 

“ 七 — W 3 h*t you -to build. 

togcthcir a feaiu\rc lisi ; i h lahjua^c 
七 he dus-tomc\r Uhdc^rs-t^hds. 

/Wake sumc youv W whal ihc 
亡 ustomeir adually wahts. 

^gye!opr»ehi Affvoa^k^ 

— c j^ iveh developr^eh-fc, -takes a sih^le use 
Gse m youv sysiern, av\d ^oduscs oh 匕。州 pletihg 
|"the Code io inr\plcnr\Ch*t that Ch*ti\rc use CBst, 
ihdludihg dll of i-ts sdCharios, bcW r^ovi^ oh io 
*hythihg else ih the dfpliddiioh. 

ga 七 ur e djrivch develo^gh-fc, -Poduscs oh b sih^le 
eaiu\rej a^d dodcs all behavior of ihai 

C 3 *tu\rc ； bc-Po\rc ^ov'mj oh *to 3 hy*thihj else ih *thc 
fplidatioh. 

扣 veh devdopr^ghi wvites tcs£ sdehdvios 

ov * a pi 设 d -Puhd-tiohality bc-forc writ— the 

*("OV~ 4*Uhd*tioh31 i*ty. T~liCh you wv*i*tc 

[o^twavc -to pass a!! the icsis. 

ood so^twavc dcVclopnr»Ch*t USUdlly ihdovpovatcs 

— 1 L°^ *t^ csc dcvclopnr\Ch*t models a*t di-P-Pcrch-t 

stages o+ -the dcvcloprwch-t dyde. 
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OOA&D Cross 

Lots of new terms in this chapter, so lots of little 
square boxes to fill in for this chapter’s crossword. 
Review the chapter and see if you can get them all! 



Across 

3. Never be afraid ic da this m d&sign„ 

4. This type of programmeprot&cts you and 
focused on prevenrting errors and invalid data, 
6. Vou should te^t your software for this kind 
of 

11. Iterating your deveJopfTient on 

Specific pi&ces of fynctiflno ity.. 

12, Feature driven develepirient is very 


15. Goad development is driven by these. 

16. CuS+Dfnfir^ just want their Software to do 
this, 

17. teveloping your software, ba^ed on 
Scenarios through □ 

18.. Setting Stuck trying to decide on one 
design decision or another. 


tiown 

1. This is what you u 包 e to prove to the 
customer that ycur software works. 

2. Program this way when you trust yaur 
and they trust you. 

5. Testing weird and strange u 过 aged of your 

code wifi help you catch errors_. 

7. Use ca^e. diogram^ and feature Fists don' t 

make Sense 十 。 the _ 

B. [>e^ign de[iskns are afway5 a _ 

9. A ^ingfe test con focus on r^any 
pieces of functionafity. 

10. Great SDf ti>yare written fike this. 

13„ Vflu write 兽 of 十 ware for the_, 

1A, Once ycu chaose □ feature or use ca^e 」 you 
need to do this agdrv 
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Excise 

、 *1 • 

^^LvtlPHS 
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Feature Driven Development, Use Case Driven Development, 
Programming by Contract, and Defensive Programming have 
all showed up for a masquerade party, but none of them bothered to 
wear name tags. They’re all a chatty bunch, though, so it’s up to you 
to listen to what they’re saying, and try and figure out who’s behind 
the masks. Be careful.... sometimes more than one masked guest 
could be saying the same thing. 


I prefer to take 
me, until I’ve 
inish. 

e would call, 
but how can you really believe 
anyone anymore? 

Oh, absolutely, requirements really 
get me motivated. 


Use Case Vrmv\ Pevelopmewt 


Pefemive Programming 


Feature Privcw Pevelopmeht 
Use Case 9rmv\ Pevdopmwt 


>u rwiglvt have added 

Pvojvarwmmg by 
Cov\brditi 

a is \redl!y B 

(orn\ o( \rc«\ui\rcrwch-ts. 


I’m very well-behaved. In fact, I’ve been 
focusing on all of my own behavior 
before moving on to anything else. 


Feature Vrmv\ Pevelopmeht 


Really, it’s all about my customer. I 
just want to satisfy them, after all. 

Hey, you’re a big boy. You can deal 
with that on your own... it’s really not 
my problem anymore, is it? 


All of them! 


^r 


Proqrammiwg by Cohtract 




^11 Jc t^ese 

*be 6 W<YACs a 灼 d 

avc vc3Hy 3kou*t 

so^*bv^av-c 七七 
i\\ej 命七 . 


As long as you’re good with it, so 
am I. Who am I to tell you what to do, 
so long as you know what you can 
expect from me. 


Programming by Contract 
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Putting It 


Honey, I think you’re a great 
programmer, but I just don’t see how 
youre going to combine all those little 
bits and pieces into anything that 
makes sense. 


All Together 


You may not see it yet, Walter, 
but rm going to take all these 
pieces and turn them into one big 
beautiful cake of 00 goodness. 
Just you wait and see... 


Are 


we 


ere 


We’ve been working on lots of 


individual ways to improve your software, but now it’s time to 


put it all together. This is it, what you’ve been waiting for: we’re 


going to take everything you’ve been learning, and show you 
how it’s all really part of a single process that you can use over 
and over again to write great software. 


this is a new chapter 









assembling the pieces 

developing software, OOA^P style 

You’ve got a lot of new tools, techniques, and ideas about how 
to develop great software by now... but we still haven’t really 
put it all together. 

That’s what this chapter is all about: taking all the individual 
things you know how to do — like figuring out requirements, 
writing up use cases, and applying design patterns — and 
turning it into a reusable process that you can use to tackle 
even your trickiest software problems, over and over again. 


So what does that process look like? 


Feature list 

Figure out what your 
app is supposed to do 
at a high level 



Use Case Piaqraws 

Nail down the big 
processes that your app 
performs, and any external 
forces that are involved. 


greak Up the Problem 

Break your application up 
into modules of functionality, 
and then decide on an order 
in which to tackle each of 
your modules. 


I 


RequireweKits 

Figure out the individual 
requirements for each 
module, and make sure those 
fit in with the big picture. 



The Object - Orie+ed Analysis 


1 Make sure your software ctoes wkat tke customer wants it to cto 


Does rt seem like you a LOT o( iime 
y/ovv-yihg about -fuhdiiohaliiy? Thai's because 
you do... i-f ^us*tomc\r ish ’ 七 y/i*tK 
v/ha 七 youv so-fiv/av-c docs, you y/cm ’ 七 suddeed. 
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to a^cr — 卜，孙 d 

^ascs a— 


use 


-tV^csc 


km- 


Iterative Development 


1 

PomaiKi Analvsis 

Figure out how your use 
cases map to objects in your 
app, and make sure your 
customer is on the same 
page as you are. 

Prelimmarv Pesiaw 

Fill in details about your 
objects, define relationships 
between the objects, and 
apply principles and patterns. 

ImDlemeHtatioH 

Write code, test it, and make 
sure it works. Do this for 
each behavior, each feature, 
each use case, each 
problem, until you're done. 


delivery 

You’re done! Release your 
software, submit your 
invoices, and get paid. 


备 Pesign Project Lifecycle 


jL 


II 


%. Apply basic 00 principles 
to add flexibility. 






3 . Strive for a maintainable, 
reusable ctesigfn* 
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skeptical? 


Look, I love your pretty arrows 
and all those labels, but I'm not 
convinced. Weve used parts of that 
process, but how am I supposed to 
know using all those steps together 
like that really works? 


Let’s build a software 
project，from start to 
finish, using this process. 

We’ve used all of the different parts of 
this process to work on software projects 
throughout the book, but we haven’t yet 
really put it all together. But that’s all 
about to change... we’re going to let you 
build a pretty complex piece of software 
in this chapter, from feature list to 
implementation and delivery. 

Along the way ， you’ll see for yourself how 
all the things you’ve been learning really 
do help you build great software. Get 
ready, this will be your final test. 


O 
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OOA&D Magnets 


◦^^^^^^nswers^his exercise d 。 mT 


Before we dive into the problem we’re going to be solving in this chapter, you 
need to make sure you see where all the things you’ve been learning fit in the 
big OOA&D Project Lifecycle. At the bottom of this page are OOA&D magnets for 
lots of the things you’ve learned about already; your job is to try and put those 
magnets on the right phase of the OOA&D lifecycle, shown again below. 


You can put more than one magnet on each phase, and there are some magnets 
you may want to use more than once, so take your time, and good luck. 


Wve stairtcd a list 4^ 



You 63^ ^ 
as wa”7 t«wcs as l>kc- 


oi tV^csc 
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objectville travel 


The problem 


Here’s the project we’re going to work through in 
this chapter, fron^g^mm^^^nd ： 




Objectville Travel, Inc. 

210 Tourist Ave. 
Objectville, HF 90210 


Statement of Work 


Congratulations! Based on your amazing work for RickS Stringed 
Aments and Doug^ Dog Doors, weM like to comnnssxon you 
to program our brand new Objectville Travel RouteFmder. 

With the recent increase in travel to Objectville 
provide tourists an easy way to see the wonderful H== ake 
Obiectville so unique. The RouteFinder should be able o stor 
Objectville^ complete network of subway lines, as we as a ^ 
stations along each line. Objectville^ subways are state-of , 

and can go backwards and forwards between stations, so you don 
need to worry about the direction of any of the mes. 

The RouteFinder should also be able to take a starting station, and a 

destination station, and figure out a route to trave = r === S 
should be able to print out the route, indicating which lines to take, 
which stations are passed on a line, and when travelers may need to 
get off one line and get on another at a connecting s a 誰 . 

We pride ourselves on flexibility and extensibility in Objectville, 
r W e expect the RouteFinder to be easy to extend as we come up 
with new ways to provide our tourists the best experience aroun m 

object-based travel. 

We look forward to seeing your design and a working RouteFinder 
soon. We’re all counting on you! 


Sincerely, 




Orbin Traveloctic, CEO 

PS To help you get started, we’ve provided a map of Objectville s 
subway lines, and a file with all of the stations and lines. 
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This m 七 eirtiohally blank, 

SO you ddn 匕 U"b out "the tool 

Objcdivillc Map OY\ -the hC^*t 
dhd i*t up oy \ you\r dubidle v/dll 


二士⑵:工爲广 e 
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0])jec{ville SuWay JVfef 


Legend 

O Local train station 

® Interchange with 
other lines 



Booch Line 



Gamma Line 


Jacobson Line 


Liskov Line 


Meyer Line 


Rumbaugh Line 



Wirfs-Brock Line 






Weather-O-Rama, Inc. 


JavaBeans Boulevard 
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SRP Square 


Head First 


▲iounge 


IViiglity GximbaH ， Itie 


We're 


OPEN 


OljjectviUe 2 ) [ml 


GoF Gardens 


OOA&D Oval 


SimUDuck Lake 


Head First Labs 


Web Design Way 
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scratch paper 


This m*tcn*tiohally bla^k ； so 

you ddh du*t ou*t *thc too\ Okjcd*tvi||c 
< Map oy \ -the pvfvious 

i*t up oy\ youv dubidle v/dll 
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H^harpen your pencil 


k Write the feature list for the RouteFinder app. 


We’re throwing you right into things. Your job is to take the Statement 
of Work on page 488, and use it to develop a feature list. You can refer 
back to Chapter 6 if you need help on what features are, and what a 
typical feature list looks like. 



You doh ； i liavc -fco use 
^11 o( tKcsc blanks \( 
you dor!{, tKihk you 
iKem all. 
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RouteFinder feature list 


t^harpen your pencil 

answers 


Write the feature list for the RouteFinder app. 

Your job was to take the Statement of Work on page 488, and use it to 
develop a feature list for the RouteFinder we’re going to build. 


HevVs Y/iidt d3r»»C uf Vrtiv 
YouV ay\sv/CV*s m3y 
ours c^attly, but should 
be pvetb/ tlosc, ar\d to^cc 
*tv>csc same basic, -fouv ^aiuvcs. 


A 'valid V'ou'tc^ be 

all Oh OhC lihC, o\r ihVolve 

several di-P4vchi ke. 


Obiectville RouteFinder 

Feature List 


1. We have to be able to represent a subway lim 

and the stations along that jme. 

2. We must be able to load multiple subway lines 

into the program, including overlapping lines. 

$. We need to be able to figure out a valid path 

between anv two stations on any lines. 

4. We Meed to be able to priwt out a route 




between two stations as a set of directions. 


Uhes overlap wKeK> 
"they bo*tK shdire 七 ) 

砧 me s-ta-feioK>. 


> s a sc ? avd ^ C 
{“七认代… suV_c 
You V^avc tW«s m 70 UV 
<C3"b'A' rC 1' 15 七 . 


D 


thevf ar 

umb ( 


e no . 

Questions 


Why aren’t we gathering requirements? I’m still 
not clear on how a feature is really that different from a 
requirement, anyway. 


Why did you list printing out the route as a separate 
feature? That’s pretty easy once you’ve got a valid route 
between two stations, isn’t it? 


Features and requirements are often used almost 
interchangeably. Most of the time, though, people say “feature” 
when they’re talking about BIG things that an application needs 
to do. So it might take several requirements to satisfy one 
feature. And since features are usually a little bigger-picture 
than requirements, it's a good idea to start any new project by 
writing out a feature list, like we’ve done with the RouteFinder. 


It probably will be, yes. But the feature list isn’t just 
a list of hard problems you have to solve—it’s a list of a" the 
things your application has to be able to do. So even if a feature 
seems easy or trivial, put it on your feature list anyway. 
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Now you should really know 
what youYc supposed to do 


At this point, you’ve finished up that first phase. 



With a feature list in hand, you should have a good 
understanding of the things that your app needs to 
do. You probably even can begin to think about the 
structure of your application, although we’ll spend 
a lot more time on that in just a bit. 

Once you’ve got your feature list down, you should 
move on to use case diagrams. Those will help you 
connect what your app does to how it will be used — 
and that’s what customers really are interested in. 


Your leature lists are all about uncterstaiiciiiig 
wkat your software is supposed to cto. 


Your use case ctiagrams let you start tkinking 
about kow your software will te usect ，witkout 
getting into a tunck ol unnecessary cietailst 
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use case diagrams 
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- Feature Magnets 



Once you’ve got your use case diagrams figured out, you need to make sure that 
your use cases match up with the features you have to deliver to the customer. 
Below is the feature list for RouteFinder, as well as magnets for each feature. Place 
each magnet below on one of the use cases you filled in on page 496. Make sure 
you have each feature covered before turning the page. 


Obiectville RouteFiwder 

Feature List 


Represent subway lines, and 
stations along each line. 


詹 We have to bg able to represent a subwaf line,, 
awd the stations along that line. 



2. We must be able to load multiple subway lii 


iwto the program, including overlapping lir es: 


Load multiple subway 
lines into the program. 


$• We need to be able to figure out a valid pan 


between awv two stations on any lines, 


Figure out a valid route 
between two stops. 


4. We weed to be able to priwt out a route 

between two stations as a set of direction 


Print directions for a 
particular route. 



Ea^K ohc o( -tKcsc majheis 
sKould Jo oh ohC of -feKc use 
ovc\r Kc\rc- 



Vo\a avc HERE. 
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Excise 

-• 

^PLvtlPHS 


Decide on the structure for the RouteFinder code, and map your 
use cases back to your feature list. 

You had a Sharpen Your Pencil, and a Feature Magnets to solve. You 
were supposed to figure out the actors and use cases for your system, 
and then make sure those use cases covered all the features we 
decided RouteFinder had to support. 


o 


八 

Administrator 

r - r , 

You m •吵七 have 七 do 鄭 Travel 

ov- ano-tV\cv -fov 
•tWis 匕 ” jus-t make you 
had someone load ，％ … ttc 
0bjc6*tv'illc subway \\r\ts. 


o 


八 

Travel Agewt 

(or Tourist) 


TW»s A-catuvc »s v-c<\u«v-co 
-fundtio^al'rbY ^or tWis 
use tasc to >wov-k, so v/c 
a*t*ta^cd V>cvc. 


subway Imcs 


Represent subway lines, and 
~ > stations along each line. 

load network of^~— - 


Load multiple subway 
lines into the program 



给 et directions 


Figure out a valid route 
between two stations. 


Print directions for a 
particular route 



么上 n y 7 严 ？ 咖相 a 
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the ooa&d lifecycle 


Use cases reflect usage, 
features reflect fuwctiowalitv 

Let’s look more closely at one of the feature-use case 
matches we showed you on the last page: 


^ - - ^1 Repress 

Load network 
subway WmsmKM 


Represent subway lines, and 
〉ns along each line. 


/ 



The “Load network of subway lines” use case really 
does not directly use our feature that deals with 
representing the subway. Obviously, we have to be able 
to represent the subway for this use case to work, but 
it’s a stretch to tie the two together like this. 

That’s not a mistake, though; when we’re writing 
use cases, we’re dealing with just the interactions 
between actors and a system. We’re just talking about 
the ways that your system is used (which is where the 
term U use case’’ came from). 


n '[^ RouieFi^ 


do a 


use case io wovk ; but 


TV^csc avc 叫 $ tVia-t ouv- 

used. 





Load network of 



Represent subway lines, and 
stations along each line. 


The features in your system reflect your 
system’s functionality. Your system 
must do those things in order for the 
use cases to actually work, even though 
the functionality isn’t always an explicit 
part of any particular use case. 


A use tasc may dt^d ^ a -to 

WW, but He may ^o-t a^tual v 

be J W step m He “sc use rbc . 

Toad mW" subv/ay lmcs , dc^ds a 

吧奶 taW “如 subv/ay, Ut uses 
七 -featuve mdivc 匕七 1 丫 


fo\A avc (still) HBRB- 


Feature 

Use Case 

Preak Up the 

Requirements 

domain 

Preliminary 

List 

diagrams 

Problem 

Analysis 

Pesign 


Implementation 
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features and use cases 


D 


thevf ar 

umb ( 


e no . 

Questions 


Didn’t you say that I should be able to match up every 
feature to a use case in my system? 

Yes, and that’s still true. Every feature in your system will 
be at least a part of addressing one or more uses cases in your use 
case diagram. But that doesn’t mean that the use case has to actually 
directly use that feature. Lots of times, a feature makes it possible 
for a use case to function without being directly used by the use case 
itself. 

In our RouteFinder, there would be no way to load a network of 
subway lines into the system (one of our use cases) without having a 
representation of a subway in the first place (one of our features). But 
the “Load Network” use case doesn’t have any steps that match up 
directly with that feature... the steps in the use case just assume that 
a representation of the subway exists. So the use case indirectly uses 
the feature, without explicitly referring to it. 




So is a use case a requirement, or is a feature a 
requirement? 

A! Both! Use cases are requirements for how people and things 
(actors) interact with your system, and features are requirements 
about things that your system must do. They’re related, but they are 
not the same. Still, to implement a system’s use cases, you’re going 
to need the functionality in the system's features. That’s why you 
should always be able to map your features to the use cases that 
they enable and are used by. 


What happens if I find a feature that I can’t match up to a 
use case, even indirectly? 

A! You should take a hard look at the feature, and make sure 
it really is a required part of your system. Your customer—and her 
customers—only interact with your system through the use cases. 
So if a feature doesn’t at least indirectly make a use case possible, 
you’re customer really isn’t going to see a benefit. If you think 
you’ve got a feature that doesn’t really affect how your system is 
used or performs, talk it over with the customer, but don’t be afraid 
to cut something if it’s not going to improve your system. 


Tke features in your 
system are wkat tke 
system ctoes，anct are not 
always rellectect in your 
use cases，wkick skow kow 
tke system is usect. 

Features anct use cases 
work togetker, tut tkey 
are not tke same tiling. 
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The Big Break-Up 

We’re starting to pick up some steam. With use case diagrams in place, you’re 
ready to break this problem up into some smaller pieces of functionality. There 
are several ways to do this in any application, but our goal here is to keep the 
RouteFinder system very modular. That means keeping different pieces of 
functionality separate — each module should have a single responsibility. 

Go ahead and break up the RouteFinder system into four different “modules”. 
Think carefully about the best way to break up your system... it isn’t necessarily 
going to line up with your four features (although it might!). 



"the hdrvtC o-p 

wha 七 "tKis module 
does ih ilic blahk. 



Remember you heed io 

^ dlc ^ WW • 七 y 

bu'you a | So hC ed to pv^ovc io 
^ustoirhC\r iha-t youv- system 


the 

wo\rks. 


WcVc v-cally rirvov'mj alo^j- 



Feature 

List 

Use Case 
diagrams 

Preak Up the 
Problem 

Requirements 

domain 

Analysis 

Preliminary 

design 

Implementation 
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breaking up isn’t hard to do 


TKeBig Break-Up, Solved 

We’re starting to pick up some steam. With use case diagrams in place, you’re 
ready to break this problem up into some smaller pieces of functionality. 


TV>csc modules make 

u ? tV>c system... 从 q 
a w bla 6 k bo/ tKat is used by 
W«sts av^d travel -to 


TV\c Subway module V\as all 

从 c todt 铷 at 代 ycscvAs 
stations, 

brb/w i^ost stat 。 响 ad 

t^hrt subway system 
iiscl^. It also 1 ^ 0 邮 Vu>v/ 

{jo y-t divetto^s ^v-om o^c 
^tatiov^ -to a^otKcv- ov^ its 
6o^cC.t«ov\S a^d 1 •… es. 


a Tcsi i 


… 3 Module, 



^ ^dded 
because w 

^Iiy p^r J°" c dodc ^ 



dould have several di-PWht wavs 

匕 load V ubw ^ ： ^ a ^ ilc > with 
^ i^ui or CVCh a 地 basc 

L ^ d,h 9 is ^'y 唧的 td | he 

SU 7 a y ^P^Chtatioh So H 

jets i-fcs own module. 


pvmtms is a lot like load_ 
• ，七、 sc\>av-atc -fv-om i\\t 
sub^dY 〒七 cw i-tscl-f. TV>»s 
module V^a^dlcs 
subv/a^ *to a^Y device ov- 

衽 at v/c m 吵 t ” 《 d’ 


% s "t is ouisidc ihc 
s ystd i 七 ir\ic\rS^£s 
wi 仏仏 e system but 
?^i o( 

system i-tscl-P. 



^ Which 00 principles are we using? 

Check the box next to the 00 principles you think we’re using to break up 
the RouteFinder functionality in this manner. 



Single Responsibility Principle 
Don’t Repeat Yourself 
Encapsulation 



Delegation 

Polymorphism 

Liskov Substitution Principle 


J\^crs 

? ay 
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Now start to iterate 



Once you’ve broken up your software into several individual pieces 
of functionality, you’re ready to start iterating over each piece of 
functionality, until the application is complete. 

At this point, we need to take our big-picture view of the system, 
from our use case diagram, and refine that into requirements that 
we can begin to tackle, one by one. For this first iteration, let’s take 
the “Load network of subway lines” use case, and turn that into a 
set of requirements that isn’t so big-picture. Then we can take care 
of that use case, and iterate again, working on the next use case. 


八 

Administrator 


\A/cVc 谈叫 七 ？ 

use 63SC W 
our d\ayam, 



arpen your pencil 



Load network o 
subway lines 



fret directions 




iflrpen your pencil 

What approach to development are we using? 


Write the use case for loading subway lines. 

Turn that little oval into a full-blown use case. Write the steps 
that RouteFinder needs to take to implement the “Load network 
of subway lines” use case. 



Y°^ use 

mo 代 s£cp s； 

y° u ^cd them. 


Not too sure about lliisuse ease? It’s OK... turn the pa^e for some help... 


Iteration 
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whafs a subway? 



How am I supposed to write this use 
case? I’m not totally sure I know what a 
subway line even is yet. And what about that 
file that Objectville travel said they were going 
to send over to us? Won’t that affect how we 

write our use case? 


o 



You’ll often have to do some extra 
work between breaking up the 
problem and writing your use cases. 

You’ve just uncovered a “secret step” in our process 
for writing software the OOA&D way: 


sometimes r\ttd "to idkt - 〜 


iJvSerswT 

theProblevw 


” ydo，t 州 “ 

p:bi—n w 心 
etteir <TC^ui<rcrhChts yd. 


oulr 


Feature 

List 

Use Case 
diagrams 

^reak Up the 
Problem 

Requirements 

Pomarn 

Analysis 

Preliminary 

Pesign 

Implem ⑼ tati(m 



If you get stuck writing a use case, there’s nothing 
wrong with taking a step back, and examining the 
problem you’re trying to solve a bit. Then, you can 
go back to your use case, and have a better chance of 
getting it written correctly. 


^ WcaWm ”？ 

•tWrCC wod^cs, 
^cVc maWmoy sure 
caA V\ 3 S 

reason 

•bo 


Sharpen your pencil 

answer 


ch^apsula-fecd 

P …仏 3 扣 d loadi^ 
—W ： vav-y. 

whi^ should XI 
s ^y ihe s3^ c . 



answers Which 00 principles are we using? 

Check the box next to the 00 principles you think we used to break up the 
RouteFinder functionality into separate modules. 


|Single Responsibility Principle 
Don’t Repeat Yourself 
Encapsulation 




Delegation 
Polymorphism 
Liskov Substitution Principle 


M’s v\oi dleav- 
•*P wcVc usihj 
dclcja-tioh 
al+hough 
with 撕 ahd 
c^dapsulatiorj ； wc 
probably will a-fe 
some poi^-fe- 
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me is d scv-'ics 




: adV\ 
办 ev". 
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WcVc Itcvatioir. I, 

Use — 

6 asc ： UdH a 从 

sub^av V»ir\CS. 



A closer look at representing a subway 

Before we can figure out how to load a subway line, there are two 
things we need to get a good grasp of: 

o Understanding the basics of what a subway system is. 

❺ Understanding the information an administrator would have 
when they’re loading a set of subway stations and lines. 


What is a station? 

A subway system has stations, and connections between those stations, 
and lines that are groups of connections. So let’s begin by figuring out 
exactly what a station is. 


s*taW、 s a 
? omt or. ^ 
a 一 c. 



OOA&D Oval 


And a connection between two stations? 

As soon as you start adding several stations, you’ve got to deal with the 
connections between those stations: 




* II — 



OOA&D Ova I 

These av-c bo 七 
s*t3*tioy\S, Wrtii 
d simple y\amc. 




This is 

P 扣 t a subway |i h( 


Vi 


Sim U Duck Lake 


\ 


Then a line is just a scries of connections... 

If you put several connections together, then you’ve got a subway line. 



stations, t 
or\t *to a^< 


issdolaAap SA-CP assisn 


o--J 0a.eljo sjL4ujD)ujsn0M 

0JB-t—< u0UJdol0> 0p 01 LjoBOJddBlcoLIAA 


BBS J 

■ 1 JSA uae-Dlg 


A〆 


Iteration 









loading a subway network 


Let's take a look at that subway file 


We’ve got a basic idea now of what a subway is, so let’s see what kind 
of data we’ve got to work with. Remember, Objectville Travel said 
they would send us a file with all the stations and lines, so this should 
give us an idea of what an administrator will use to load the lines into 
the subway system. 


-f ile Objcttvillc 

Tv-avcl s ⑶七 us *to load 
subway Ues 心。州 . 


Ajax Rapids 
HTML Heights 
JavaBeans Boulevard 
LSP Lane 
Head First Labs 
Objectville PizzaStore 
UMLWalk 

XHTML Expressway 
Choc-O-Holic, Inc. 

Head First Theater 
Infinite Circle 
CSS Center 
OOA&D Oval 
SimUDuck Lake 
Web Design Way 
... more station names... 


-file s-tavis out 
wi-tK a list o-f all -tKc 


Booch Line ^ 

Ajax Rapids 
: HTML Heights 
JavaBeans Boulevard 
LSP Lane 
Head First Labs 
Objectville PizzaStore 
UMLWalk 
Ajax Rapids 

Gamma Line 
OOA&D Oval 
Head First Lounge 
OOA&D Oval 


TWis is 
o-f 七 W … 

… 如 d licvc avc iKc 

statiohS oy\ *tKis 
line, ih ovdcir. 

Smtc these Imcs -fov-m loo\>s, i\\t 
Jp iv . s -t s-tation also a\>\>ca« as 
las-t s-tatio^, -fov-m'mj a 


Jacobson Line 


■ - TKcvc is an empty line 

^ .…. bcty/ccr\ eadK suby/av line. 

Servlet Springs \ ’ 

■■ more stations on this line... A 
..more lines.. 




Feature 

Use Case 

Preak Up the 

Requirements 

Pomain 
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Problem 

Analysis 

design 


Implementation 
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arpen your pencil 

Write the use case for loading subway lines. 


You should have enough understanding of what a subway system is, and 
the format of the Objectville Subway input file, to write this use case now. 



use 

oy 

mo 代 sieps, i-f 

y° u iherh. 


Iteration 
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the finished use case 


parpen your pencil 

answers 


Write the use case for loading subway lines. 


You should have enough understanding of what a subway system is, and 
the format of the Objectville Subway input file, to write this use case now. 


The step is 七 he 
s*ta\rt dor\dii*tior\ ： 七 lie 
loadcv* yts d r\cw -file 
*to lodd -f\rorw. 


P'»di 70U yt tW»s stc\>? 
^ v-ca»7 (Wt o 炚 

svstem to v^avc 
station... ttat toM be 

3 ^V-oWcw latcv- OY\- 

Hc^rcs a^o-tKcy stc? 
y/V^cv*C V3lid3"tc 

*to make SUV-C *tV)C 

tovmcfrbov^ ’》s valid 
七 he tuv-v-cv^t suby/ay- 


^teps like this, whidh ^ 
•mdidatc \rcpca-tihj o-th^7 
steps, help intake youv 

use cases a liiilc ⑽代 

^C^d^blc (toh^isc. 




load network of subway lines 

Use Case 

1. The administrator supplies a file of stations and lines. 

2. The system reads \v\ the name of a station._ 

$. The system validates that the station doesn't already exist 

4 . Ibc system adds the new station to the subway. 

5. The system repeats steps 2-4 until all stations are added. 

6. Ibc system readiiw thc name of a liwei^adl_ 

7 The system reads m two stations that are connected. 

S. The system validates that the stations exist_ 

9. The system creates a new connection between the two 

stations, going iiC both direcfioP^QH the current line. 

1Q. The system repeats steps 7-9 until the line is complete. 

11. The system repeats steps 6-10 until all Imes are entered. 


D 


thevf civ 

umb 1 


e no . 

Questions 


This is \rcally owly 
ohc possible way *to 
w\ri 七 e 七 lie use dase- 
Instead of dv-catmg a 
w SubwayL'mc ，； object, 
wc dedided *to jus 七 
give 七 he subway 

Cddll dOWWCdtlOh^ 

and assodiatc the 
dowhCdtiow a 
pa\rtidulav- subway lihC. 



My use case looks totally different. Is your use case the 
only solution to the puzzle? 


Y ou didh’t have ijo 

wiritc this dowh ； 

but wc -thought 
w3s irhpoirtolh't 
io \renrteimbev~ 
that subways ih 
^bjcdivillc d5h 
90 ih BITHBR 
dilrcd'tioh. 


I didn’t add any steps about validation to my use case. Is 
that OK? 


A! No, not at all. By now you realize that there are lots of 
decisions you have to make to solve any problem, and our use case 
simply reflects the decisions we made. We’re going to work with this 
particular use case throughout the rest of this chapter, so make sure 
you understand our reasoning behind it, but it’s perfectly OK if you 
came up with your own use case that solves the same problem of 
loading a network of subway stations and lines. 


A! Validation is something that you should add to your use 
case if you left it out. Making sure the stations for a connection 
actually exist is a lot like not having a dog door automatically close. It 
seems innocent enough, until the real world creeps in, and someone 
misspells a station name. Suddenly, you have the equivalent of 
software rodents: a connection that goes to a non-existent station. So 
if you left out validation, be sure to add it in to your own use case. 
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Uf s see if our use case works 

The use case for loading a network is a little tricky, and has several 
groups of steps that repeat. Let’s check the flow of things against our 
text file before we go on to analyzing the use case, and starting to 
design the classes in our system. 

su ?? l«es a ^ tWis ^ 

s'ystcw loader- 


Ajax Rapids)^ 


HTML Heights 
JavaBeans Boulevard 
LSP Lane 
Head First Labs 
Objectville PizzaStore 
UMLWalk 

XHTML Expressway 
Choc-O-Holic, Inc. 
Head First Theater 
Infinite Circle 
CSS Center 
OOA&D Oval 
SimUDuck Lake 
Web Design Way 
... more station names. 


养 Z. The system \reads m a 

s*tcl*tion ndrmC- 

养孓 TKc system makes suve 
*tKis s-tation altcddY 
been Chtcvcd in. 


养午 • "Hie sys-tem adds tKc 
station *to sub>way. 

养弓 . TKc system repeats 
tKcsc steps uniil dll tKc 
stations avc c^tcv-cd- 


[ooch Line^ 
AjaTRapids 
HTML Heights 
JavaBeans Boulevard 
LSP Lane 
Head First Labs 
Objectville PizzaStore 
UMLWalk 
Ajax Rapids 


TKc s 


ir\3nr\C 


iystem \redds 
o-r d line- 


Jamma Line 
OOA&D Oval 
Head First Lounge 
1QA&D Oval 

Jacobson Line 

Servlet Springs 

... more stations on this line... 


itn. T\)C system vedds m tKc t>wo 
ststio^s dorvhedted on line- 

#0. TKc system makes suve both 
s-tations adiually c 乂 ist on -tKc subway. 

^r°{. TKc sysiem dv-catcs a y\c^i 
dohnedtioh between tKc s-tatiorvs. 

#10. TKcsc sic^>s avc vcpcaicd 
-fov suddessive paiv o-f 
s*tatio 灼 s on 七 lie line. 

#11. TKc chtivc ^>vodcss o-f 
adding a line is v-c^catcd -fov 
eddK line m tKc -file- 


... more lines... 




Iteration 
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_A ⑽ lysis and Design Puzzle 


This time, it’s your job to take on two phases of the OOA&D process at once. 
First, you need to perform textual analysis on the use case below, and figure out 
the nouns that are candidate classes, and the verbs that are candidate operations. 
Write the nouns and verbs in the blanks provided below the use case. 


load network of subway lines 

Use Case 

1. The administrator supplies a file of statiohs md lihes. 

2. The system reads \v\ the hame of a statioh._ 

3. The system validates that the s t ation doesn't already exist 

4. the system adds the new station to the subway_ 

5. The system repeats steps 2-4 uhtil all s tat ions are added. 

6 . The system reads ih the name of a lihe to add. 

1 The system reads m two statiows that are cohwected. 

S. The system validates that the statiohs exist._ 

9. The system creates a hew cowwectioh between the two 

statiohs, qoihq ih both directiohs, oh the current \m. 

10. The system repeats steps 7-9 until the \m is complete. 

11. The system repeats steps 6-10 uhtil all lines are entered. 

Nouns (candidate classes): 


Verbs (candidate operations): 



510 Chapter 10 

































the ooa&d lifecycle 



It’s on to preliminary design. Using the candidate nouns and verbs you got from 
the use case, draw a class diagram below of what you think the subway system 
might look like modeled in code. Use associations and any other UML notation 
you think will help make your design clear and understandable. 


This o-f puzzle 
is domdnrv 



… and "tKis pa\r*t is 
pvclirwihavy desi^h. 


Feature 

Use Case 

Preak Up the 

Requirements 

domain 

Preliminary 

List 

diagrams 

Problem 

Analysis 

design 


Implementation 



Iteration 
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Analysis and Design Puzzle Solutions 


load network of subway lilies 

Use Case 

1. The administrator supplies a file of stations and lines. 

2. The system reads in the name of a station._ 

$. The system validates that the station doesn't already exist. 

4. £hc system adds the new station to the subway. 

5. The system repeats steps 2-4 until all stations arc added, 

6. the system reads in the name jf a line to add. 

7 The system reads m two stations that arc connected. 

S. The system validates that the stations exist. 

9. The system creates a new connection between the two 

stations. flomgJu both directions, on the current line. 

1Q. The system repeats steps 7-9 until the line is complete. 

11. The system repeats steps 6-10 until all lines are entered. 


W(C k>rvo>M 

七七 at*tov-s 
avc ou*tsidc 
iKc sysicrw, 
so yvo dass 
needed heve ， 


Nouns (candidate classes): 

a^inSttfafer -swfem- 


4 e- 


statioH 


This is 如 ihpu-t -to ouv 

„oi somcihihg 
WC ㈣ 細扣 ou<r system. 


These avc easy … iKcy all 
oh ouv dlass diajv-a* 

^ subway 

connection 






line 


l/Ve dedided no 七 "to dveate 
3 i-inc dldss … move oh 
wlicn you *tuvh *tlic page. 


Verbs (candidate operations): 


Wc use Javas 
I/O o\>CV-at>oir\S -to 


supplies a file 
-一 rea^te-w- 


V^d^dile 七 Wis. 


validates station 

adds a statioKi 


^ adds a coKiyiectiow 

Most d ttese a^tiv 
{p wet^odis oy\ ouv- classes. 
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T V,e actual loader 6lass 


：^:W 


lc- 



TKis is iKc •^3ih ob\cd 七 

^ii * ^ 

v/e II be y/ov-kihj y/iiK, av\d 
wc heed s method "to 
add s-taiiohs, av\d h> add 

fiohhcfrtiohs. 


This dlass uses dll -tKc ■Puhd'tiohali'ty 
^jj. Subway -to tYtait a subway -Pvom 
Z^ 000 ^^ -Pile o-(* s^-tiohs 3hd lihes. 


Subway 

addStation(String) 
hasStation(String): boolean ^ 


addConnection(String, String, String) 


n/ou should V,avc _ed o 吃 

Io,^use ， ase^ 7 -' 

y^eed oyerabo^ ^ » 

伽 e A. TW，s — 
o( validate staWs, m 如 ? s 
#2* a”d 非弓 . 


£ubv/dY V^ds d 6ollcttioir» o-f 

七 he s*tat»oir\s *m ttc suby/^Y ， 
as v/ell as 七 he 七 》 o 朽 s 一 

amo^j its stations. 


stations / * 


connections' * 


Station is 、 

siw^lc... it has a 

灼 d 你 c, dy\d s 

about it. Well tomt 
batk {p >m^y >mc 
added airv e«\uaU() 
awdi KasiiCodicO 
method m d w»mu 七 e. 


Station 


name: String 


getName(): String 
equals(Object): boolean 
hashCodeQ: int 




A 6owC6-t»ov\ V^as 
•tvio station av\d 
七 y\3wC "tV^C 

1'mC t^C towCtt»ov\ 

is a \>avt o-f. 



V® u should hoj ； dall iKcsc attv-ibuic! 
S"ta\rt ahd s-top, o\r bejihhin^ a^d 
ehd, s\y\U subways ih ^bjcdivillc 
9° both y/ays. I/Vc jus-t y/eivt v/i-tli 
sis-iionl Sr\d sta-tiohZ. 


Wve do'mg design a^d heading -toy/av-ds 
im^lcmCh*ta*tion -fov *tliis i*tc\ra*tioh. 
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design decisions 


To use a Line class or not to use a 
Line class... that is the question 

It was pretty easy to look at our use case and figure out that we 
need a Station, Connection, and Subway class — those 
are fundamental to our system. But then we decided to not 
create a Line class. Instead, we just assigned a line name to 
each connection: 


L'mcs ov\Yj 

3S StvmJ 灼 arwCS 

*to 


Connection 

station 1: Station 
station2: Station 
lineName: String 

getStation1(): Station 
getStation2(): Station 
getLineNameQ: String 


We made this decision based on one thing: we know how the 
system is going to be used. In the original Statement of 
Work (back on page 488) from Objectville Travel, we were told 
we needed to represent a subway, and get directions between 
one station and another. Once we have those directions, we can 
simply ask each connection for its line; there doesn’t seem to be 
a need for an actual Line class. 


Your ctesign 
ctecisions skoulct 
te based on kow 
your system 
will te usect，as 
well as good 00 
principles. 
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thevf civ 

umb 1 


e no . 

Questions 



I found the "validates that a station exists” verb, 
but where does that operation appear on any of the classes 
in your design? 

A: We modeled that operation as hasStation () 
on the Subway class. You could have called that operation 
validate () or validatestation (), but those aren’t 
as descriptive as hasStation (), and you should always try 
and make your code as readable as possible. 

Could you talk a little more about how you showed 
those repeated steps in the use case? 

A! Lots of times a use case has a set of steps that need 
to be repeated, but there’s not a standard way to show that in 
use cases. So we just made one up! The point of a use case 
is to provide you with a clear set of steps that detail what your 
system should do, and we thought the clearest way to show 
those repeated steps was to write down “Repeat Steps 7-9." 

I’ve been thinking about that subway 
representation, and it looks a lot like a graph data structure 
to me. Why aren’t we using a graph? 


Wow, you must have taken a data structures or 
algorithms class recently! Yes, you can use a graph to 
represent the subway. In that case, each station would be a 
node, and each connection would be a labeled edge. 

So then why aren’t we using a graph structure in 
this example? 

We think it’s really overkill in this situation. If you 
already know about graphs and nodes and edges, and you 
happen to have code for that sort of data structure lying 
around, then go ahead and use them. But from our point of 
view, we’d do more work adapting a graph to our needs than 
just coming up with a few simple classes for station and 
Connection. Like almost everything else in the design 
stage, there are several ways to solve a problem, and you need 
to choose a solution that works well for you. 

You lost me on the whole graph thing... what’s all 
this about edges and nodes? 

A! It’s OK; you don’t need to know about graphs in order 
to understand and solve this particular problem. It's nothing to 
worry about, at least until we come up with a Head First Data 
Structures book (anyone? anyone?). 


des.^ de6-,s T s ..一 a loiof —dU ⑽ 
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the station class 


Code the Station class 

We’ve got requirements in the form of a use case, a class 
diagram, and we know the Station class will fit into our 
Subway model. Now we’re ready to start writing code: 




% dame up -the 

Subway module badk 
page ^01. 


Oh 


l-f you v/a 此 you - — 
tav\ pu-t S*taiioy\ 
m a f>adkage like 
objctivillcsubv/ay* 

|*t ； s up *to you i-f you 
>way\i {p bv-cak up youv- 
modulcs by ^adkaje- 


public class Station { 
private String name; 

public Station(String name 
this.name = name; 

} 

public String getName() 
return name; 

} 



TV^'is »s ouv- tlass diayam -fov- 
-fv-om 州 c 犯 • 


A ^"ta-tioh is basically 
just a named objedt 


public boolean equals(Object obj) { 

if (obj instanceof Station) { 

Station otherStation = (Station)obj; 
if (otherStation.getName()•equalsIgnoreCase(name)) 
return true; ^ --- Y - - ^ 


TKis cK»suircs ; 4ir example, iKa-t a 
earned w AJAX RAPIDS is 
tovys\d^d -the same as a sia-tio^ 
u Ajax Rapids ;; . 


return false 


public int hashCode() 

return name.toLowerCase().hashCode(); 

} 


1 L 

\A/e -fi^uv-edi tteves jomj *to be a lo 七 
of tom\>aviso^s stations, so v/C 

made suve dr(Wd c«\uals(). k tVus 
vision, W Siafeoy, objedis a^rc c«\ual 

•,Jp *tV\cy V^avc ttc sar»»c 



^ base the hash udt o( a 0h 

r" c samc that dompav-isohs 

based on ： -the o( ihc states 


d lo*t move oy\ c^udlsO 3^d 
V^asiiCodicO, diictk ou*t l^> 

of Head Pnrst Java- 
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When you override equals() in 
Java, you should usually also 
override hashCode() to ensure 
correct comparisons. 


The Java specification recommends that if two objects 
are equal, they should have the same hash code. So 
if you’re deciding on equality based on a property, it’s 
a good idea to also override hashCodef) and return 
a hash code based on that same property. This is 
particularly important if you’re using your object in a 
Hashtable or HashMap, which both make heavy use 
of the hashCodeQ method. 
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Sharpen your pencil 

\人 Write the ( 


Write the Connection class. 

Using the class diagram on the right, complete the 
Connection class by filling in the blanks with the correct lines 
of code. Be sure your class will compile before you turn the 
page and see our answers. 


public class Connection 


private 

r 


private 

• 

f 


public 

Connection( 





this . 

=stationl; 


this . 

=station2; 


this . 

=lineName; 


} 



public 

0 

{ 


stationl; 


} 



public 

0 

{ 


station2; 


} 



public 

0 

{ 


lineName; 




WcVc well m*to 七 he 

七 ion pKasc o-f ouv 
•fivs 七 i 七 eva 七 ion, now. 
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the connection class 



\ answers Write the Connection class. 

Using the class diagram on the right, your job was to fill in 
the blanks and complete the Connection class. 


public class Connection { 


private Station 

stationl ， station^ 

private StridOl 

liHeName ； 

public Connection ( Station StatiOdl , 


Striwa lineName ) 

this, stationl 

=stationl; 

this. statiowi 

=station2; 

this. lineName 

=lineName; 

} 

public Station 

getStationl () { 

return stationl; 

} 

public Station 

aetStatiow2 () { 

return station2; 

} 

public Striwa 

cietLineName o { 


return lineName; 


Subway 


Connection 


stationl: Station 
station2: Station 
lineName: String 


getStation1(): Station 
getStation2(): Station 
getLineNameQ: String 


Station statiowi 


Vou av-c HERE. 
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Code the Subway class 

Next up is the Subway class itself. With Station and 
Connection done, and a good class diagram, nothing 
here should be a surprise: 


public class Subway { 

private List stations; 
private List connections 




Subway 

stations: Station [*] 
connections: Connection [*] 

addStation(String): Station 
hasStation(String): boolean 
addConnection(String, String, String): Connection 


public Subway() { 

this.stations = new LinkedList(); < 

this.connections = new LinkedList(); 

} 


^ csc wi,1 all 

the dohhcdti 
bciv,c ^ ^os C si3ii 0 ^ 


public void addStation(String stationName) 
if (!this.hasStation(station)) { ^ 

Station station = new Station(stationName); 
stations.add(station); 

} 

} 


pivs-b, v/c validate make 

suve v/c do^i already tW.s station- 

S-b-tioh ahd add i-fe 

"to the subway. 


public boolean hasStation(String stationName) 
return stations.contains(new Station(stati 


。一'•工心 

^~ suWys stator Ust 


public void addConnection(String stationlName, String station2Name, 

String lineName) 

if ((this.hasStation(stationlName)) && 

(this.hasStation(station2Name))) { 

Station stationl = new Station(stationlName) 

Station station2 = new Station(station2Name) 



Like ^ddS't^'tiohO ； wc 
with some validaiioh ： -this 
y/c make su^c both 
s-t^-tiohs cxis-fc ir» -fclic subway. 


Connection connection = new Connection(stationl, station2 , lineName) 
connections.add(connection); 

connections.add(new Connection (station2, stationl, 

connection.getLineName())) 

else { 

throw new RuntimeException (''Invalid connection!"); 



T 


cvroir 


‘dl c ^ d 故 wh 辦 。叱 J ^ 

states -the do^edtioh dot^i exist. 


TW,s .s V|RV 立⑽ 
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understand the system 

Poiwts of interest ow the 
Objectville Subway (class) 

We threw a couple of new things into the Subway class; 
first, you’ll see this line of code quite a bit: 

Station station = new Station(stationName); 


For example, when we create a new Connection, we 
have code like this: 

Station stationl = new Station(stationlName); 
Station station2 = new Station(station2Name); 
Connection connection = 

new Connection(stationl, station2 , lineName); 


Lots of programmers would take stationlName, 
and iterate through the list of stations in the Subway 
class to find the Station object that has a name of 
stationlName. But that takes a lot of time, and there’s a 
better way. Remember how we defined an equals () and 
hashCode () method on our Station class? 


_Station_■ 

name: String _ 

getName(): String ■ 

equals(Object): boolean ■ 

hashCodeQ: int _ 

These methods allowed us to tell Java that when it 
compares two Station objects, just see if their name is 
the same. If the names are equal, even if the objects don’t refer 
to the same location in memory, they should be treated as the 
same. So instead of looking for a particular Station object 
in the Subway class’s list of station, it’s much easier to just 
create a new Station and use it. 


Ko^allv, e r als() m Java 融少淑 
i ^ 0 ob\ctts actually a^rc ttc 。'^ 七 … 

m ottev N^ords, \i looks {p see ttcy a^rc 

adtuallv -to ttc same m 

But tKaVs NOJ ^ to use 
心 r to^\so^ oi W S-tatioL okjedts. 


Because we overrode equals() and 
hashCode()，we can save search time 
and complexity in our code. Your 
design decisions should always make 
your implementation better，not more 
complicated or harder to understand. 
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What Java's default equals!) implementation does, 



TKcsc W mstaws 丨 厂如 saw 

y,amc ; Ut ^ to Uo dMt^i 
lodatio 灼 s … so c<\ualsO says ： 


These two stations are NOT equal! 


Object.equals() 


What our equalsO implementation does. 


TW»s wakes ouv- 

•ur»^pl C^C 妁 *^3七.’ o 灼 

todt a b'»5 ? am - 


0yAY 败 sion o( c^ualsO tells Java io base 
equality oh iKc value o( iKc attribute, 
i^s-tcad o( a mcmo\ry lo^atioh. 



These two stations ARE equal! 


Station.equals() 


Ihi s ^rcsuli ^9ke 
^calihj witt £iai\ 
cdsiev*. 


•Ohs 




D 


thevf ar 

umb < 


e no . 

Questions 


What does any of this have to do with OOA&D? 


A! This is the very core of what makes OOA&D useful: because 
we understand our system, we realize that two stations should be 
considered identical if they have the same name. And, our design is 
improved by being able to compare stations based on their name, 
rather than their location in memory. 


So the time we spent on requirements and getting a good grasp of 
our system made our design better, which in turn made implementing 
that design a lot simpler. That’s the power of OOA&D: you can turn 
knowledge of your system into a flexible design, and even end up 
with cleaner code—all because you spent time up front listening to 
the customer and gathering requirements, rather than diving right into 
an IDE and typing in source code. 
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abstract your classes 



Why aren't we just taking in a 
Station object in addStationQ, 
and a Connection object in 
addConnectionQ? Wouldn't that 
make sense? 


Frank: That’s true. So we could change our Subway class to look 
more like this: 


stations: Station [*] 
connections: Connection [*] 



addStation(Station) 
hasStation(String): boolean 
addConnection(Connection) 


Joe ahd FVa h k 把 

，蚨 ih 
ob j^ts (ov these 

广 stHhjs that 

p pbp 吻 values 

iolr 仏 0 处 objedh. 


Jill: But then you’re exposing the internals of your application! 

Joe: Whoa... not sure what that means, but it sure doesn’t sound like 
something I want to do. What are you talking about? 


Jill: Well, look at our code right now. You don’t have to work with a 
Station or Connection at all to load up the subway. You can just call 
methods on our new Subway class. 

Frank: How is that any different from what we’re suggesting? 


Jill ： If we went with your ideas, people that use the Subway class 
would have to also work with Station and Connection. In our version 
right now, they just work with Strings: the name of a station, and the 
name of a line. 

Joe: And that’s bad because … 


Frank: Wait, I think I get it. Their code is getting tied in to how we 
implement the Station and Connection classes, since they 5 re having to 
work with those classes directly. 

Jill: Exactly! But with our version, we could change up Connection 
or Station, and we’d only have to change our Subway class. Their 
code would stay the same, since they’re abstracted away from our 
implementations of Connection and Station. 
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Protecting your classes (and your 
client's classes, too) 

Frank, Joe, and Jill are really talking about just one more 
form of abstraction. Let’s take a closer look: 


Subway subway = new Subway(); 

subway. addStation (''OOA&D Oval ’’）； - 

subway. addStation (''Head First Lounge ’’）； 
subway. addConnection (''OOA&D Oval”，''Head First Lounge 

Gamma Line ’’）； 



Clicht Code hcvcv deals div-cdtly 
With "the S-ta-tioh OY Cohhcd-tioh 
今 dts. Hjusi wo^ks wi-th • 咿 . 

2 


丁' ^ ⑽咖 s ⑽ 




邮七 _ 一 7 如 gyA> ^ 6la . SS 

tV>c StaW ad 

Cowc6t»or\ objects. 



You skoulct only expose clients ol your code to tke 
classes tkat tkey MEED to interact witli. 

Classes tkat tke clients don’t interact witli can te 


ckangect witk minimal client code being aHectect. 



^ 七 his y/c dould liov/ 

S-taiioh a^d CohhCfiiioh y/ov-k, ar»d ii 
v/ould^i 匕 ode iKai o^ly uses our 

Subway object; iKcyVc pvojedied -fv-orw 

dliahjcs -to ou\r implcmch-taiioh. 
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loading the subway 


The SubwayLoader class 

We’re almost done with our first iteration, and our first use 
case. All that’s left is to code the class that loads a subway 
based on the test file we got from Objectville Travel, Inc. 

public class SubwayLoader { 
private Subway subway; 

public SubwayLoader() { 

this.subway = new Subway(); 



Wre woirkihj oh 
^-oadc^r module how 
C pajc ^OZ). 


SubwayLoader 


loadFromFile(File): Subway 


public Subway loadFromFile(File subwayFile) throws 工 OException 
BufferedReader reader = new BufferedReader( 

new FileReader(subwayFile)); ^ ou-t by \oad\^ 

/ all s-b-tiohs. 

loadStations(subway, reader) 

String lineName = reader.readLine(); 

while ((lineName != null) && (lineName.length() > 0)) { 

loadLine(subway, reader, lineName); 
lineName = reader . readLine (); 穴 O^Ct ^o*t 



return subway; 


nCtA "to 

w, sWld w a w 

add states 
Vmc wW/. 


private void loadStations(Subway subway, BufferedReader reader) 


throws IOException { 

String currentLine; 
currentLine = reader.readLine(); 
while (currentLine.length() > 0) 
subway.addStation(currentLine); 
currentLine = reader.readLine() 


,° ad，h 3 M • v . 

n— 知 ) u ihio °T 巧—占 

hhl ^ a bl, hk li hc iheh 



station aficr t^at- 


private void loadLine(Subway subway, BufferedReader reader. 

String lineName) 

throws IOException { 槪 ^ station, a^d 

String stationlName, station2Name; 
stationlName = reader.readLine() 
station2Name = reader.readLine() 

while ((station2Name != null) && (station2Name.length() > 0)) { 

subway.addConnection(stationlName, station2Name, lineName); 
stationlName = station2Name; 
station2Name = reader.readLine() 
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MetkoJ Magnets 


Let’s see exactly what happens when you call loadFromFileO in SubwayLoader, and 
give it the text file we got from Objectville Travel. Your job is to place the magnets 
from the bottom of this page — which match up to methods on the SubwayLoader 
and Subway classes — next to the lines in the text file where they’ll be called. 


Tlicvc avc ohly ^ mciKods iKai 
involved Kcvc, bui you II 
"to use most o( ilicsc mdjheis 
seveval times eddK. 



^bjcd-tvillcSubway.-tx-t 


Ajax Rapids 
HTML Heights 
JavaBeans Boulevard 
LSP Lane 
Head First Labs 
Objectville PizzaStore 
UMLWalk 

XHTML Expressway 
Choc-O-Holic, Inc. 

Head First Theater 
Infinite Circle 
CSS Center 
OOA&D Oval 
SimUDuck Lake 
Web Design Way 
... more station names... 

Booch Line 
Ajax Rapids 
HTML Heights 
JavaBeans Boulevard 
LSP Lane 
Head First Labs 
Objectville PizzaStore 
UMLWalk 
Ajax Rapids 

Gamma Line 
OOA&D Oval 
Head First Lounge 
OOA&D Oval 

Jacobson Line 

Servlet Springs 

... more stations on this line... 
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Metkod Magnet Solutions 


Let’s see exactly what happens when you call loadFromFileO in 
SubwayLoader, and give it the text file we got from Objectville Travel. Your 
job was to place the magnets from the bottom of this page next to the 
lines in the text file where they’ll be called. 



TV^c Loader slants by 
tv-catmj a ^ 
object, 

“11— loadStaWsO. 


loadStati-ofts () M 
Ajax Rapi ^ ad ii^tation () 
HTMLHeinii add i c itr]f inn f) 


1 ^ 


ad( 


JavaBeai 
LSP Lan( 

Head Fii 
Objectvil 
UMLWa 
XHTML Express 


： 4g^aJtion 0 
ation j-Y 




addSt 


^kl^^ion () 


addStation() 

mes... 


Choc-O-Holic, In 
Head First 
Infinite Cir 
CSS Cen_ 

OOA&D 0 
SimUDuck . 

Web Design 
... more station n 

Booch Line 
Ajax Rapids 
HTML Heights 
JavaBeans Boule 
LSP Lane 
Head First Labs 
Objectville PizzaStor 

UMLWalk _ ,、 

Ajax Rap i ds ^^dC— ctlon () 

Gamma Lind 10 ' 


K 




\ s ^n C( ji 


loadL'mcO gets dalled 
a 七七 he bcgmnmg of 
cadK now line. 


ad( 


)nn( 


addConnection() 

Qage-G t-iori- j 
addConnection() 


.總 r 


-a-d-dCo-n-j 


in () 


OOA&D Oval 


Head First Lounge 
OOA&D Oval 


addConnection_Q 

addConnection () 


Jacobson Line 
Servlet Springs 




… more stations on this line... Lg^j^_ Qnne ction () 
... more lines... 
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Test Puzzle 


You’re almost done with the first use case, and our first iteration! All that’s left is 
to test out our solution, and make sure it actually works. 

The problem: 

You need to test loading the Ob jectvi lie Subway. txt file, 
and make sure that SubwayLoader correctly loads in all stations 
and connections in the file. 

Your task: 

o Add a method to Subway to check if a particular connection exists, given 
the two station names and the line name for that connection. 

o Write a test class, called LoadTester, with a main () method that loads 
the Objectville Subway system from the text file we got from Objectville 
Travel, Inc. 

o Write code in LoadTester that checks a few of the stations and 

connections from the text file against the Subway object returned from 

SubwayLoader’s loadFromFile () method. You should check to 
make sure that at least three stations and three connections on three 
different lines were all entered correctly. 

o Run your test program, and verify that we’re really done with Iteration 1. 


ttcvc’s 七 he use 
*tcstnr»^ m 

七 Wis 


load network of subway liwes 

Use Case 

1. The administrator supplies a file of stations and lings 

The system reads in the mm of a station._ 

S. The system validates that the station doesn't already gyist. 

4. The system adds the new station to the suhway. 

5. the system repeats steps 2-4 until all stations are added. 

6. The system reads \n the name of a liwe to add. 

^The system reads in two stations that are connected. 

8. The system validates that the stations exist._ 

9. The system creates a new coHwection between the two 

stations, going in both directions, on the current line. 

1 0. The system repeats steps 7-9 until the line is complete. 

U The system repeats steps 6-10 until all lines are entered. 


Testing is v-cally pav-t o( 
the implcmch-ta-tioh pKase- 
Code isr> ■(： Complete Uh*ti| 
•is tested- 
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Test Puzzle Solution 


Your job was to test the Subway Loader and our subway representation to 
make sure you can load a subway system from a text file. 


o Add a method to Subway to check if a particular connection exists, given 
the two station names and the line name for that connection. 


TWis is \>v-cHy 

•i 七 rtcva 七 es 七 Wou 吵 

subway ； a 灼 d jus 七 
6om\>av-CS I'mc 
a^d s-tafeo^s -to see i-f 一 




public boolean hasConnection(String stationlName, String station2Name, 

String lineName) { 

Station stationl = new Station(stationlName); 

Station station2 = new Station (station2Name); 
for (Iterator i = connections.iterator(); i.hasNext(); ) { 

Connection connection = (Connection)i.next(); 
if (connection.getLineName().equalsIgnoreCase(lineName)) { 

if ( (connection.getStationl() .equals(stationl)) && 

(connection.getStation2().equals(station2))) { 

return true; _ 

Subway 

stations: Station [*] 
connections: Connection [*] 

addStation(String) 
hasStation(String): boolean 
addConnection(String, String, String) 
hasConnection(String, String, String): boolean 


return false; 



Sub ， 


D 


ttere ar 

imb < 


Wouldn’t it be easier to write the hasConnection() 
method if we used a Line object, like we talked about a few 
pages ago? 


e no . 


if we had a Line object. 


It would. If we had a Line object, we could look up the line 
using the name passed into hasConnection (), and just iterate 
over the Connection objects for that line. So in most cases, 
hasConnection () would involve less iteration, and return a 


We still decided not to use a Line object, though, because we’ve 
only added hasConnection () to help us test our classes. 

So adding a Line object just to make a test method return 
faster doesn’t seem like a good idea. If we find that we need the 
hasConnection () method in other parts of our app, though, this 
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public class LoadTester { 

public static void main(String[] args) { 

try { 

SubwayLoader loader = new SubwayLoader(); 

Subway objectville = 

loader . loadFromFile (new File (''Ob j ectville Subway. txt^)); 
System. out. print In (''Testing stations ...〃）； 
if (ob j ectville . has Station (''DRY Drive") && 

obj ectville . has Station (''Weather-O-Rama, Inc.〃) && 

◦bj ectville • hasStation (''Boards 、 R/ Us")) { 

System. out. print In station test passed successfully. ^); 

} else { 

System. out. print In station test FAILED."); 

} System.exit (-1); y ou use ^ 

s-tsfco^s 
like V^cv-c- 


System. out .printIn ('、\nTesting connections . 
if (objectville .hasConnection (''DRY Drive", 

''Head First Theater ^, ''Meyer Line^) && 

obj ectville . hasConnection (''Weather 一 0 一 Rama, 



工 nc • 

''XHTML Expressway” ， ''Wirfs-Brock Line") && 
objectville .hasConnection (''Head First Theater ”， 

''Infinite Circle", ''Rumbaugh Line") ) { 

System, out .println . . .connections test passed successfully.^); 
} else { 

System, out .println . . .connections test FAILED. 〃）； 

System.exit (-1); 

} 

catch (Exception e) { 

e.printStackTrace(System.out); 


class 
Load- 
Tester 
main ()] 


LoadTester.java 


o Write a test class, called LoadTester, with a main () method that loads 
the Objectville Subway system from the text file we got from Objectville 
Travel, Inc. 

o Write code in LoadTester that checks a few of the stations and 

connections from the text file against the Subway object returned from 

Subway Loader’s loadFromFile () method. You should check to 
make sure that at least three stations and three connections on three 
different lines were all entered correctly. 



"Hiis todt simply passes ih 
七 ^ 七以七 "Pile ； dhd "tliCh 
tesis a -few sia*ti 0hS ahd 
dohhCdtiohS -fco sec i-f 
jo-t loaded. 

〆 


Iteration 
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test and iterate 



Test Puzzle Solution (cont.) 


Your job was to test the Subway Loader and our subway representation to 
make sure you can load a subway system from a text file. 



Run your test program, and verify that we’re really done with Iteration 1. 


File Edit Window Help NotVeryExciting 


% java LoadTester 
Testing stations.•• 

•••station test passed successfully. 

Testing connections... 

...connections test passed successfully. 


cAcitihg to 
You 

; 七―卜外卜 



Try and write a test case that gets all the stations and 
connections in the Subway and prints them out, to 
verify your subway is loading the network correctly. 


Ifs time to iterate again 

Our test proves that we really have finished up our first iteration. 
The “Load network of subway lines” use case is complete, and that 
means it’s time to iterate again. Now, we can take on our next use 
“Get directions” 一 and return to the Requirements 


Load network of 
subway lines 


1/VcVc dohe Kcvc. 


case- 


and work through this use case. 


fret direction 





Feature 

Use Case 

List 

diagrams 




domain 

Analysis 


Preliminary 
design 


Implementation 


Oi\tt av\ 'i*tcvatio>r> IS i-f 

3v*c w»ov*c use CBscs ov •(■c3*buvcs 
■to •• 叫 leme 此 you yveed {p take youv 
七 -fc3*tuv*c ov use tasc ； a>r»d s-t3v-*t 
aja'm at \rc<\u'»vcmcn-b ^asc. 
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Put before we start Iteration 1 



It’s teen a LONG iteration，anct you’ve 
ctone some great work. STOP , take a 
BREAK , amt eat a Lite or ctrink some waten 
Give your train a ckance to REST* 


Tkeii, once you’ve caugfkt your Lreatk, turn tke 
page，and let’s knock out tkat last use case. Are 
you reacty? Tken let’s iterate a gaiiu 




Weak bcW 沪吶 


you are here 


5 


Iteration 1 


Iteration 2 


31 




















how far have we come? 


Whaf s left to do? 


We’ve made a lot of progress, on both our use cases, and 
our feature list. Below is the feature list and use case 
diagram we developed earlier in the chapter: 


Obiectville RouteFiwder 

Feature List 


Represent ^Pbway lines, and 
stations\^.ong each line. 


i. We have to be able to represent a subway lme. 

awd the stations along that line. 


^ W of both ^ 
+catu<rcs ih lioraii 咖非 I 


Load multiple subway 


2. We must be able to load multiple subway Hl 1in .„ inWthe program . 
mto the program, ihcludinq overlapping linear 

炙 We heed to be able to figure out a valid ou t a valid route 

between a^v two stations on any lines. I between two stops. 

4. We need to be able to priwt out a route 

between two stations as a set of dj 



Travel Agent 
(or Tourist) 


to — 。加 S . 


Wcvc also ouv 
tasc tsken tav-c o-f- 


use 


This use dasc is ihc 4 dus o( 
ouv " s Cdohd i-tcv-a-tior>. 
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Pack to the requirements phase... 

Now that we’re ready to take on the next use case, we have to go 
back to the requirements phase, and work through this use case the 
same way we did the first one. So we’ll start by taking our use case 
title from our use case diagram, “Get directions,” and developing 
that into a full-blown use case. 



Feature 

Use Case 

Preak Up the 

Requirements 

Pomain 

Preliminary 

List 

diagrams 

Problem 

Analysis 

Pesign 


Implementation 




Sharpen your pencil 


Write the complete use case for “Get directions.” 

We’re back to writing use cases again. This time, your job is to write a 
use case that allows a travel agent to get directions from one station to 
another on the Objectville Subway. 



Iteration 1 
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the get directions use case 


Sharpen your pencil 

answer 


SIHSWGrS Write the complete use case for “Get directions 


Jus-fe like ouv -Pilrs-fe 
use case, you 
should Kavc added 
some vdlidd' (: ioh. ■ 


TW«S «S b'»a \ 

-task V>avc "to 
-tatklc m tWis 

•itcvafco 灼 . 


夺 et directions 

Use Case 

1. The travel agent gives the system a starting station 

awda station to travel to. 


2. The system validates that the startimand ending 

stations both exist oh the subway. 

，炙 The system calculates a route from the starting _ 

station to the endmq station._ 

， 4. The system prints out the route it calculated._ 


Oi\tt >wc i^avc a v-ol 
should be pv-ciiy simple. 






These -the two 
modules well be wovkih 3 
with -to pu-t -this use 

乙 ase iivfco 3tiior\. 


rm a little confused. We 
went to all that work to break 
our code up into modules, but our use 
cases involve code in more than one 
module. Why do we keep jumping 
back and forth between modules 
and use cases? 
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Focus on code, thcw focus cm customers. 

Thcw focus ow code, thew focus ow customers 


ttt 


When we started breaking our application up into different modules way back 
on page 502, we were really talking about the structure of our application, 
and how we are going to break up our application. We have a Subway and 
Station class in the Subway module, and a SubwayLoader class in the 
Loader module, and so on. In other words, we’re focusing on our code. 


our 6odc, 

\,oy» our system used, 



0(4 卜 


But when we’re working on use cases, we’re focusing on how the customer uses 
the system — we looked at the format of an input file to load lines, and began to 
focus on the customer’s interaction with your system. So we’ve really been going 
back and forth between our code (in the Break Up the Problem step) and our 
customer (in the Requirements step): 


This step is about ouv 
todt, dyvd Ko>w >wc Weak 
叶 -fuyvdtioyvality- 


TKis step is aboui 
how "tllC dus-tomev- 
uses ouv so-f-twavc. 


Feature 

Use Case 

Preak Up the 

Requirements 

domain 

Preliminary 

List 

diagrams 

Problem 

Analysis 

Pesign 


Implementation 



When you’re developing software, there’s going to be a lot of this back-and- 
forth. You have to make sure your software does what it’s supposed to, but it’s 
your code that makes the software actually do something. 


It’s your jot to balance making sure tke customer 
gets tke functionality tkey want witk making sure 
your cocte stays flexitle anct well-ctesig[nect. 


Iteration 1 


Iteration 2 
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textual analysis and preliminary design 



-Analysis and Design Puzzle 


It’s time to take on more domain analysis and design for your system. 
Take the use case below, figure out the candidate classes and candidate 
operations, and then update the class diagram on the right with any 
changes you think you need to make. 



5orhc of 

邮 • Wio, of you , 
, ydc 


^et directions 

Use Case 

1. The travel aaent gives the system a starting station 

awd a station to travel to._ 

2. The system validates that the starting and ending_ 

stations both exist on the subway._ 

$ t The system calculates a route from the starting _ 

station to the ending station._ 

4. The system prints out the route it calculated._ 


Nouns (candidate classes): 


Verbs (candidate operations): 
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Add m av.7 classes, 

at^Wtes, a，d 

，tWk 产巧 ascd 

U r uv a^s»s or ， 


YVC'/'O^ 


SubwayLoader 


loadFromFile(File): Subway 




Feature 

Use Case 

Preak Up the 

Requirements 

Pomain 

Preliminary 

List 

diagrams 

Problem 

Analysis 

Pesign 


Implementation 


M \re -fcKcsc -two pKase 
oy\ ai -feKc sa»»»c djaih. 
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class diagrams 


A ⑽ lysis and Design Puzzle Solutions 


^ khow we i\ttd B hew dldss ijo 
^ 3 K»dlc p\rih"tih^ d V"ou*tc ov\tt v/( 
yt i 七 *Pv~om "tlic £ubv/dy ^l^ss. 


printPirectiohs(Comiectioii C* 3 )) 



Tins is 七 he w\ 3 i^ add'rbo 灼 … 
v/e i\tt& *to be able to \>ass 
•m 七 he a s 七 av " 七 

s*b3*biov \； dvtd c^d s*b3"bion, 
a^d y 七 a se 七 of divcttio^s 



TW»s *ta^^ 

二)。》 


a ^tc as a sci o( 
^i iohs Ud 

ilUd 
ihc i-t s o,；. 


stations / * 



^ IVc did^t show the r\our\s ar\d verbs... by 
y\oy/, you should be dom-fo\rtablc y/i-th *tha*t 
s*tcp, ar\d be able -to *brar\sla 七 e {\\t^ m*to 
*thc dldss didyrdm shovm here. 
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Iteration makes problems easier 

The class diagram on the last page really isn’t that much 
different from our class diagram from the first iteration (flip 
back to page 513 to take a look at that earlier version). 
That’s because we did a lot of work that applies to all our 
iterations during our first iteration. 



Subway 




Wt did d LOT o( y/ovk \v\ ou\r -firs-t 
rtcv*^tion … y/c wovkcd oy\ modules, 
Completed eivtive use dasc. 


kadjietwork of suhway li^ 
Use Case 

e administratorsiipplio. a f eo f. 


: stations and {mgs 


esystew reads in the name of a station 

hi system validatps that the stating doesn't alrcariy 0 v；, t 

OVStew aridQf^ rw ^imion tnt^p Q.fh^y 

_啪 a r— 

㈣ of a li ⑽忉州 

1 that 抓 仙咖 aw 

S '~ sys tew validates that the sfatinwo ex j stt 

9 . The system i 


Once you’ve completed your first iteration, your successive 
iterations are often a lot easier, because so much of what 
you’ve already done makes those later iterations easier. 



f\\\ -tKc 讀 k … c o 於 

七 V>c Subway module laid 
七 youy\di>wovk -fov ouv* 

sedo^d »*tcv 


u ncoriy 一 rriv 

did ih -the -Pil 
/VJosi < 
Subway module is 
Ad wc v c cv Ch jo 

SorhC tests ih p | 况 


1/VcVc veady bo move -to tiic 
implementation please... but "tW»s "»tcv3t» 
•is movm^ d loi -fastev, a^d t^cv-cs less 
{p do, ^iv*st rteva 七 io 朽 . 

\ 


Feature 

Use Case 

Preak Up the 

Requirements 

domain 

Preliminary 

List 

diagrams 

Problem 

Analysis 

design 


Implementation 



Iteration 1 


Iteration 2 
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getting directions 


Implementation: Subway.java 

Figuring out a route between two stations turns out to be a 
particularly tricky problem, and gets into some of that graph stuff 



we talked about briefly back on page 515. To help you out, we’ve 
included some Ready-bake Code that you can use to get a route 
between two stations. 


public class Subway { 
private List stations; 
private List connections 

private Map network; ^ — 




public Subway() { 

this.stations = new LinkedList(); 
this.connections = new LinkedList(); 

this.network = new HashMap(); ^ - 


/ 

Rcad 7 -bakc todt is todt 

alvcadv U 70 U. 

Just m as .ts sV^o^ V>cvc, 

ov- vou dovi^load a 
vcvs-.or, 0-f SO ) 叫 java 心⑽如 

Head P'ivs-t Labs v/cb sVtc ， 


// addStation(), hasStation(), and hasConnection () stay the same 


540 


public Connection addConnection(String stationlName, String station2Name / 

String lineName) { 

if ((this.hasStation(stationlName)) && 

(this.hasStation(station2Name))) { 

Station stationl = new Station(stationlName); 

Station station2 = new Station(station2Name); 

Connection connection = new Connection(stationl, station2 , lineName); 
connections.add(connection); 

connections.add(new Connection(station2, stationl , 


connection.getLineName())) 


addToNetwork(stationl, station2); __ 

addToNetwork(station2, stationl); 

return connection; 
else { 

throw new RuntimeException (''Invalid connection!"); subway s ^c*t>wov-k 


VVKew we add wc y\ttd 

{p update ouv Map o( stations, 



private void addToNetwork(Station stationl, Station station2) 
if (network.keySet().contains(stationl)) { 

List connectingstations = (List)network.get(stationl); 
if (!connectingstations.contains(station2)) { 

connectingStations•add(station2); 

} 

} else { 

List connectingstations = new LinkedList(); 
connectingStations•add(station2); 


^is w 仏 。 d 


dowi 


h ,s dodc. 
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Ouv V^as as 

station. TV>c value ^ siahor^ 

• 1S a Ust to^\^ all stators 

\i dometts {p (vcjavdlcss ok 
▲，匕 Umc siaho^s). 
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network.put (stationl, connectmgStations); 


public List getDirections(String startStationName, 

String endStationName) { 
if ( !this.hasStation(startStationName) 

!this.hasStation(endStationName)) { 

throw new RuntimeException( 

''Stations entered do not exist on this subway . f, ); 



知七广 d Chd statiohs that 

WC i, ou^ use 

Use oh page 兄午 • 


Station start = new Station(startStationName); 
Station end = new Station(endStationName); 

List route = new LinkedList(); 

List reachableStations = new LinkedList(); 

Map previousStations = new HashMap(); 

List neighbors = (List)network.get(start); 
for (Iterator i = neighbors.iterator(); i.hasNext() 
Station station = (Station)i.next(); 
if (station.equals(end)) { 

route.add(getConnection(start, end)); 
return route; 

} else { 

reachableStations.add(station); 
previousStations.put(station, start); 



TW«s method «s based 。的 
a v/cll -一 娜 h 七 0 和 

tailed P •• 片 a 、 al — 七一 

V/WlA ^ I^uv-cs out 
sWtes 七 ㈣ w 

⑽ dcs 


av/a ^ i o ^ 


List nextStations = new LinkedList(); 
nextStations.addAll(neighbors); 
Station currentStation = start; 


searchLoop : 

for (int i=l; i<stations.size(); i++) { 

List tmpNextStations = new LinkedList(); 

for (Iterator j = nextStations.iterator(); j.hasNext(); ) { 

Station station = (Station)j.next(); 
reachableStations.add(station); 
currentStation = station; 

List currentNeighbors = (List)network.get(currentStation); 
for (Iterator k = currentNeighbors.iterator(); k.hasNext() 
Station neighbor = (Station)k.next(); 
if (neighbor.equals(end)) { 

reachableStations.add(neighbor); 

previousStations.put(neighbor, currentStation); 
break searchLoop; 


TV^csc loo^s *to 
i-bcva-tc -bV^vou^ tat\\ set 
station readable ^ 

如 sta 咖 station 
如 hast 

number oi station ?oss»Wc 


Iteration 1 


Iteration 2 


you are here ► 
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getting directions, continued 


} else if (!reachableStations.contains(neighbor)) 
reachableStations.add(neighbor); 
tmpNextStations.add(neighbor); 

previousStations.put(neighbor, currentStation); 


nextStations = tmpNextStations; 



// We've found the path by now 
boolean keepLooping = true; 
Station keystation = end; 
Station station; 


while (keepLooping) { 

station = (Station)previousStations.get(keystation) 
route.add(0 , getConnection(station, keystation)); 
if (start.equals(station)) { 

keepLooping = false; 


keystation = station 


s 




仏” wc v ”心吨 wc 
uhwihd” the pa 仏 
aind a Lhio( 
^ C ciio„s -to jet 

-to the 

sUio, 


o 


return route 


TWis is a 乂 W 減 $ 

} (。— 7 W 入 

/ 

private Connection getConnection(Station stationl, Station station2) { 

for (Iterator i = connections.iterator(); i.hasNext(); ) { 

Connection connection = (Connection)i.next(); 

Station one = connection.getStationl(); 

Station two = connection.getStation2(); 

if ((station1.equals(one)) && (station2.equals(two))) { 

return connection; 


return null 
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OK, this is just ridiculous. I 
spent 500 pages reading about how 
great OOAAD is so you can just give 
me the hardest code in the book? I 
thought I was supposed to be able 
write great software on my 
own by now. 


Sometimes the best way 
to get the job done is find 
someone else who has 
already done the job for you. 

It might seem weird that at this stage, 
we’re giving you the code for getting a 
route between two stations. But that’s 
part of what makes a good developer: a 
willingness to look around for existing 
solutions to hard problems. 

In fact, we had some help from a college 
student on implementing a version of 
Dijkstra’s algorithm that would work 
with the subway (seriously!). Sure, you 
probably can come up with your own 
totally original solution to every problem, 
but why would you want to if someone 
has already done the work for you? 



Sometimes tke test cocte lor a particular problem kas 
alread y teen written. Don’t get kung ； up on writing cocte 
yourself ti someone atreacty kas a working solution. 


You a\rc HERE. 


Feature 

Use Case 

Preak Up the 

Requirements 

Pomain 

Preliminary 


List 

diagrams 

Problem 

Analysis 

Pesign 



Implementation 



Iteration 1 


Iteration 2 
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a series of connections 


What does a route look like? 

The getDirections () method we just added to Subway 
takes in two Strings: the name of the starting station, and 
the name of the station that a tourist is trying to get to: 



XHTML Expressway 


TWis is passed m as siatiow 


JSP Junction 


夕 


… this hamc is passed ih as -tKc 
dcs-tihatioh siatioh. 


getDirections () then returns a List, which is filled 
with Connection objects. Each Connection is one part 
of the path between the two stations: 



Infinite Circle 



TK»s t 鱗 ctW starts at 

yrtTML- ss 叫， 

aocs-to I ^ 如 CVr 如 
Rumloau^ Umc- 


Rumba ugh Line 



So the entire route returned from getDirections () looks 
like a series of Connection objects: 


T\\t -f iv-s-t 
s^a*bio^ ov\ 

Jp!V-st tovmcttuw 


is YOUV- stavtmj 




All W -tKis is vcp^csch-tcd \y\ 
a siir^le Cor\y\c^boy\ object. 



Connection 


Station 

XHTML Expressway 


Station 

“Infinite Circle 


line 


Rumbaugh Line 




Thc joes 
Uhiil H Chds i h a 

h3s 

si3i IOh il)3i 
thc dcs ii^iioy). 


► etc. 



3 

is 
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?tmn i 細 1 e 


You’re almost done! With a working getDirections () method 
in Subway, the last feature to implement is printing those directions 
out. Your job is to write a class called Subway Printer that takes the 
data structure returned from getDirections (), which is a list of 
Connection objects, and prints out the directions. The directions 
should be printed to an Outputstrearn, supplied to the constructor 
of the Subway Printer class when an instance of the printer class is 
created. 

Here’s the class diagram for Subway Printer that you should follow: 


Bcj'm by 

out 

-tKc stavtmj 
st3*tioir\. 


You tav\ y 七七 ^ 
Ime -fov* *tKis 
Cor»r»cd.t»o>r> us'mj 

Pv*_m 七七 he Ime 
ay\d station 

*to ilCdd *to>N3V*ds. 

r 

Pv’m 七 ou 七 
s*t3"tiov\ on 3 
七七 is passed ， 

A^ytirwC iKc I'mc 
pviht ou 七 
lihc dhd s*ta*tioh 
■fco gci o(( o-f... ^ 

...as v/cll 3 s *tV>c 
的 cv/ Irnc 七 0 y 七抓 . 


SubwayPrinter 


out:PrintStream 


printDirections(Connection [*]) 


Your output should look similar to this: 



a 

a:::# 1 。，“ 


伽 01 


File Edit Window Help ShowMeTheWay 


% java SubwayTester ''XHTML Expressway"、'JSP Junction" 

Start out at XHTML Expressway. 

Get on the Rumbaugh Line heading towards Infinite Circle. 

Continue past Infinite Circle... 

When you get to Head First Theater , get off the Rumbaugh Line. 

Switch over to the Meyer Line, heading towards DRY Drive. 

Continue past DRY Drive.•• 

When you get to Web Design Way, get off the Meyer Line. 

Switch over to the Wirfs-Brock Line, heading towards Boards 'R f Us. 

Continue past Boards 'R f Us... 

When you get to EJB Estates, get off the Wirfs-Brock Line. 

Switch over to the Liskov Line, heading towards Design Patterns Plaza. 

Continue past Design Patterns Plaza... 

Get off at JSP Junction and enjoy yourself! 


The las*t you should hdve is 
a Conncd-tioh the destination 
s-taiion as iKc porn 七 . 


Iteration 1 


Iteration 2 
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printing directions 



Printing Puzzle Solution 

Here’s how we wrote the Subway Printer class. You might have 
come up with a slightly different approach to looping through the route 
List, but your output should match ours exactly for full credit. 



public class SubwayPrinter { 


private PrintStream out; 

public SubwayPrinter(OutputStream out) { 
this.out = new PrintStream(out); 


user’s 


iVe bcjih by pvihtihj -tli 
s-tavtihj siaiioh... 


public void printDirections(List route) { 

Connection connection = (Connection)route.get(0) 

String currentLine = connection.getLineName(); 

String previousLine = currentLine; 
out .println (''Start out at '' + 

connection . getStationl () . getName () + '、•〃）； 
out .println (''Get on the '' + currentLine + '、heading towards 
connection . getStation2 () . getName () + ''•〃）； 
for (int i=l; i<route.size(); i++) { 

connection = (Connection)route.get(i); 
currentLine = connection.getLineName(); 
if (currentLine.equals(previousLine)) { 名 

out.println ('' Continue past 


t 


y\ 


...and 七 *fivs 七 Ime *to y 七 
oy\, as as tiic 
station bo tv-avcl Wavds. 






rr 


\\ 


i*b’s 七 he s3mC ImC, jus 七 
tiic station 

+ '、，get off the 


connection.getStationl().getName() 
else { 

out .println (''When you get to 

connection.getStationl().getName() 
previousLine + 

out .println (''Switch over to the '、+ currentLine 

'、,heading towards '' + connection . getStation2 () . getName () 
previousLine = currentLine; 


This ,oob ai the 

，(a 2 ::;: f 



If "the I'mc 

u*t how ix> 
I'mcs. 


rr 


\\ 


out .println (''Get off at 

and enjoy yourself!"); 




connection.getStation2().getName() 

fm 抑士 all 

i\\t suW/- 
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Owe last test class. 


All that we need to do now is put everything together. Below 
is the SubwayTester class we wrote to load the Objectville 
Subway system, take in two stations from the command line, and 
print out directions between those two stations using our new 
getDirections () method and printer class. 



Wic fv-ovc ouv- 
so-f*tv/3v-c v/ovks 
v/i 七 V>ou 七 some 七 es 七 
^ases and itsi classes. 


public class SubwayTester { 

public static void main(String[] args) { 

if (args.length != 2 ) { 

System. err . print In (''Usage : SubwayTester [ startStation] [endStation] ,r ); 
System.exit(-1); ’ 

} ^ i wo sUics passed i, o, the 

try { torhwaahd line -fov- -this icsi. 

SubwayLoader loader = new SubwayLoader(); 

lA/cvc tested cav-licv, 
so v/c kv\o>/ "tha 七 losdi^ 

subv/dV >wo\rks -PmC- 


Subway objectville = 

loader . loadFromFile (new File (''Ob j ectvi lie Subway. txt^)); 



if (!obj ectvilie.hasStation(args[0])) { 

System. err . print In (args [ 0 ] + '' is not a station in Objectville.") 

System.exit(-1); 

} else if (!objectville.hasStation(args[1])) { 

System. err . print In (args [ 1 ] + '' is not a station in Ob j ectville . r, ) ; 

System.exit (-1) ; ^ also validai c 

} two S^tiohS supplied 

o, the subway P 

List route = objectville.getDirections(args [0] , args[1]); 

SubwayPrinter printer = new SubwayPrinter (System, out) ; y\/^ val»di s-t 3 *t»oy\S) 

printer . printDirections (route) ; - c 3 v-outc 

catch (Exception e) { 
e .printStackTrace (System, out) ; 

— use ou\r hCW 
SubwayPvih-tcv dlass -to 
out tliC Voutc. 


Iteration 1 


Iteration 2 
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visit objectville 



Infinite Circle 


SimUDuck Lake 


Design Patterns Plaza 


EJB Estates 


% java SubwayTester ''Mighty Gumball, Inc ， ''Choc-0-Holic ， Inc.” 
Start out at Mighty Gumball , Inc.. 

Get on the Jacobson Line heading towards Servlet Springs. 

When you get to Servlet Springs, get off the Jacobson Line. 

Switch over to the Wirfs-Brock Line, heading towards Objectville Diner. 

Continue past Objectville Diner... 

When you get to Head First Lounge, get off the Wirfs-Brock Line. 

Switch over to the Gamma Line, heading towards OOA&D Oval. 

When you get to OOA&D Oval, get off the Gamma Line. 

Switch over to the Meyer Line, heading towards CSS Center. 

Continue past CSS Center... 

When you get to Head First Theater, get off the Meyer Line. 

Switch over to the Ruinbaugh Line, heading towards Choc-O-Holic, Inc.. 
Get off at Choc-O-Holic, Inc. and enjoy yourself! 


do YOU 
io 

^bjcd-tvillc "today 


s 關 


Gumball Inc 


Weather-O-Rama, Inc. 


OCP Orchard 


Choc-O-Holic, Inc. ， ；J 


Head First Theater 


Check out Objectville for yourself! 


It’s time to sit back and enjoy the fruits of your labor. Compile all 
your classes for the Objectville Subway application, and try out 
SubwayTester with a few different starting and stopping stations. 
Here’s one of our favorites: 
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the ooa&d lifecycle 



OOA&D Magnets 


Way back on page 487, we asked you to think about where lots of different things 
you’ve been learning about fit on the OOA&D lifecycle below. Now that you’ve 
written another piece of great software, you’re ready to take this exercise on, 
and see how we answered it, too. Go ahead and work this exercise again; did you 
change where you put any of the magnets after working through this chapter? 

Oh, and don’t forget, you can put more than one magnet on each phase, and 
there are some magnets you may want to use more than once. 



Feature 

Use Case 

Preak Up the 

Requirements 

domain 

Preliminary 

List 

diagrams 

Problem 

Analysis 

design 


Implementation Pelivery 



Ew though cadh appear 

° h *yy o “ … use 沒 dh as 

as you like. 




This time, answers are on the next pa^e! 


Iteration 1 


Iteration 2 
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ooa&d is about options 



OOA&D Magnet Solutions - 

Your job was to try and put the different magnets on the right phase of the 
OOA&D lifecycle, shown below. You could put more than one magnet on each 
phase; how do your answers compare with ours? 


Talk to the Customer 

Feature 


Key Feature LisJ^ , 


D 


thevf ar 

umb ( 


e ng . 

Questions 


It seems like I could put almost every magnet on 
each phase... but that can’t be right, can it? 

A: That’s exactly right. Although there are definitely 
some basic phases in a good development cycle, you can 
use most of the things you’ve learned about OOA&D, 00 
principles, design, analysis, requirements, and everything 
else at almost every stage of development. 

The most effective and successful way to write great software 
is to have as many tools as you can, and to be able to choose 
any one (or more) to use at each stage of your development 
cycle. The more tools you have, the more ways you’ll have 
to look at and work on a problem... and that means less time 
being stuck or not knowing what to do next. 


OOA&D is about kavingf 

lots ol options. Tkere is 
never one rigfkt way to 
solve a problem, so tke 
more options you kave, 
tke tetter ckance you’ll 
finct a cfood solution to 

O 1 ■画國 

every problem. 
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the ooa&d lifecycle 


Iteration ^ awyowc? 

No, we’re not going to launch into any more design problems. But, you 
should realize that there is plenty more that you could do to improve the 
design of our RouteFinder application. We thought we’d give you just a few 
suggestions, in case you’re dying to take another pass through the OOA&D 
lifecycle. 


Make loading more extensible 

Right now, we’ve just got a single class that handles loading, and it only 
accepts a Java File as input. See if you can come up with a solution 
that allows you to load a subway from several types of input sources (try 
starting with a File and Inputstream). Also make it easy to add new 
input sources, like a database. Remember, you want to minimize changes 
to existing code when you’re adding new functionality, so you may end up 
with an interface or abstract base class before you’re through. 




OOAfP yrtai 

so^Wv-c av-c oW” 

you tar\ aUay 

add ^ oy 

im^v-ovc y ouV_ 如呼 . 


Allow different output sources (and formats!) 

We can only print subway directions to a file, and the directions are 
formatted in a particular way. See if you can design a flexible Printing 
module that allows you to print a route to different output sources (like 
a File, Outputs tream, and Writer), in different formats (perhaps 
a verbose form that matches what we’ve done already, a compact form 
that only indicates where to changes lines, and an XML form for other 
programs to use in web services). 

a Wm 七 : ou 七七 

?a 七七 e 作 m Head hrsi 
Pa 七七⑽ br ideas 
you make 七 Wis >wo^rk. 
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ooa&d cross 



(the last) OOA&D Cross 

Yes, it’s a sad day: you’re looking at the last crossword 
in the book. Take a deep breath, we’ve crammed this 
one full of terms to make it last a little longer. Enjoy! 
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the ooa&d lifecycle 


Across 

2. All of your featured should map to 十 hede r ^it 
fenit : indirectily. 

3. When you override eqtiafsO In Javti r you 
^hayfd create a related implemefitation of thi^ 
method. 

5. Vour features reflect 十 his in your 
application. 

6. You dc this a nee you complete one feature 
or u^e cose. 

10. A feature Ii5t focuici cm what your 
Software_. 

12. When you complete this phase, you're, 
either done &r need to ^tfirate ogam. 

15. Break your appJIcatron up Into these, based 
on your npp _ e fuenct \ttna\ i ty. 

17. Understanding how □ system is used should 

hefp you make better_decidom 

!B. The approach to devebpm&nt we in 
K hr^ uhcipttr - (3 wurdij- 

19. Never be af raid io use □_to a 

probilem that someone eke come up with. 

21. Vour design decisions arc based cn haw th^s 
i£ u^ed wetl as good OO princrples. 

G2. Iteration problem^_■ 

23„ Each module in your applrcotion should have 
a sin^fe _ ^ 


E>own 

I. Make a Frd+ of thedc lo get yciLir devcl-ep4Tifin+ 
started. 

4 . Vflu Li^mdly create this typaof diagram 
ba^ed on your domain analysis. 

7. This iTeratl 况 Us usual Ty The toughest. 

5. OOAAbi if abaut giving you lists of thetfe, 

9 . ¥au sometiTTi£5 hmve te add a step to da this 
w/i'tli your probfenn before writing use case^. 

W. The kind of anoRysi^ that involves ip&nkmg 
to the cu^toim&r in Fanguag£ that thcr^r 
understand. 

11 This proves that your implementation fs 
working, 

13. Thefiouns In your use c<i5ft are these lypss 

of 哀， 

14. You have to balance what the customer 

wants with your Software^ _ 

16, Th^S is the Stage where you apply good 00 

30. (Jse case dra^rams f oou^ cn how year 
Software lvFIE be,_ 
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last answers 




E 站 RciSd 

•- • 

SpLvtlPHS 



554 Chapter 10 

















































































































































































































































the ooa&d lifecycle 


The jourwey's wot over... 



Now take OOA^P for a spiw ow your oww projects! 


We’ve loved having you here in Objectville, and we're sad to see you go. 
But there’s nothing like taking what you’ve learned and putting it to use on 
your own development projects. So don’t stop enjoying OOA&D just yet... 
you’ve still got a few more gems in the back of the book, an index to read 
through, and then it’s time to take all these new ideas and put them into 
practice. We’re dying to hear how things go, so drop us a line at the Head 
First Labs web site, http://www.headfirstlabs.com, and let us know how 
OOA&D is paying off for YOU. 
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appendix i ： le-ftQVers 

The Top Ten Topics 

(we didn’t cover) 



Believe it or not, there’s still more. Yes, with over 550 pages 

under your belt, there are still things we couldn’t cram in. Even though these 
last ten topics don’t deserve more than a mention, we didn’t want to let you 
out of Objectville without a little more information on each one of them. But 
hey, now you’ve got just a little bit more to talk about during commercials 
of CATASTROPHE... and who doesn’t love some stimulating OOA&D talk 
every now and then? 

Besides, once you’re done here, all that’s left is another appendix... and the 
index... and maybe some ads... and then you’re really done. We promise! 


this is a new chapter 
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assembling the pieces 

#1. IS-A awd HAS-A 

Lots of times in OO programming circles, you’ll hear someone 
talk about the IS-A and HAS-A relationships. 


IS - A refers to inheritance 

Usually, IS-A relates to inheritance, for example: “A Sword IS- 
A Weapon, so Sword should extend Weapon.’’ 



\/ 0 ^|| see 

-to as |£-A vclat»or»sWifs. 


HAS - A refers to composition or aggregation. 


HAS-A refers to composition and aggregation, so you might 
hear, “A Unit HAS-A Weapon, so a Unit can be composed 
with a Weapon object.” 


type: String 
properties: Map 


setType(String) 
getType(): String 
setProperty(String, Object) 
getProperty(String): Object 
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leftovers 


The problem with IS - A awd HAS - A 

The reason we haven’t covered IS-A and HAS-A much is that they tend to 
break down in certain situations. For example, consider the situation where 
you’re modeling shapes, like Circle, Rectangle, and Diamond. 

If you think about a Square object, you can apply the IS-A relationship: 
Square IS-A Rectangle. So you should make Square extend 
Rectangle, right? 


Rectangle 


setHeight(int) 

setWidth(int) 



Square 


setHeight(int) 

setWidth(int) 



/W R^ lc 


But remember LSP, and that subtypes should be substitutable for their base 
types. So Square should be a direct substitute for Rectangle. But what 
happens with code like this: 


Rectangle square = new Square() 
square.setHeight(10); 
square.setWidth(5); 

System. out. print In (''Height is n 




square.getHeight()); 


The problem here is that when you set the width in setWidth () on 
Square, the square is going to have to set its height, too, since squares 
have equal width and height. So even though Square IS-A Rectangle, 
it doesn’t behave like a rectangle. Galling getHeight () above will return 
5, not 10, which means that squares behave differently than rectangles, and 
aren’t substitutable for them — that’s a violation of the LSP. 

Use inheritance when one object 
behaves like another, rather than just 
when the IS-A relationship applies. 
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use case formats 


^1. Use case formats 


Even though there’s a pretty standard definition for what a use 
case is, there’s not a standard way for writing use cases. Here are 
just a few of the different ways you can write up your use cases: 


Todd and ^iwas Poq Pool： version 2.0 

What the Poor Poes 

1. Fido barks to be let out. 

2. Todd or (r\m hears Fido barking. 

3. Todd or (r\m presses the button on the 
remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back inside, 

6.3 Todd or (r\m hears Fido barki 

6.4 Todd or presses the bul| 
remote control. 

6.5 The dog door opens (again). 

1 Fido goes back inside. 

S. The door shuts automatically. 


tteve S i\\t format v/eve be ⑼ so 

I 仏 a simple, step - based formal 
七 h 七 y/orks y/cll -for mos*t srtuat’ 。⑽. 


use Use is ih a casual s 七 y| c . 丁 he 

stc P s 仏 at the system Allows av-c 
wHUch out ih 




Ibjd and ^ina J s Poo Poor, versing 2.0 
What the Poor Poes 

Fido barks to be let outside. When Todd and (Mna 
hear him barking, they press a button oh their 
remote control. The button opens up the dog dooc 
and Fido goes outside, then Fido does his business,' 
and returns inside, the dog door then shuts 
automatically. 

If Fido stays outside too long, then the dog door 
fill shut while he^s still outside. Fido will bark to be 
let back inside, and Todd or (Mwa presses the button 
on the remote control again. This opens the dog door 
and allows Fido to return back inside. 


Any al*tcv-r>a*tc paths art 
*to 如 ⑶ d of 

•m ddsudl -fovrn, and m 

a 灼 -Pov-m. 
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leftovers 


Focusing ovi interaction 

This format is a little more focused on separating out what is in 
a system, and how the actors outside of the system interact with 
your software. 


Th，S 〜屣 -focuses oh what 


at*bov-s av-c 
c%*tcv-wal *to 
i\\t 

OY\, 

ov* usC) 七 he 
〒七 



Todd and friwa's Poa Poor, version 2.0 

What the Poor Poes 

^ Actor 

System 

Fido barks to be let out. 


Todd or &ina hears Fido 
barking. 

Todd or &ina presses 
the button ow the 
remote control. 

1 

Fido goes outside. 

Fido does his business. 


Fido goes back inside. 

The door shuts automatically. 

Extensions 


If Fido stays outside and the dog door shuts before he 
comes back in, he can bark to be let back in. Todd or 
(r\m can press the button on the remote again, and he 
can return inside. 


TVis *fo\rw ^ 七 does 灼七 o\\ty d 
£.oy\VCir\ic\r\*b *t° handle al*tcv*v\3*tc 
so *t^cyVc jus*b added a 七七 k 
bottom o*f "tV^ use ^3sc* 


卜 Todd 3 hd 

dog door, the sysi Cm 
is p\rctty simple, 
usually is jus-t 
|v-cspohdiha -fco the 

l^tiohS of Todd, 
ahd Fido. 
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more use case formats 


A more formal use case 


Tiic a6*tovs ave 
c%tcv-r\al -fovtcs 
*Uia 七 

七 he sys*tcrw. 

Pv-c-toy\d'«t»on 

detail 

assumptions 

七七七 he 
svstew' w^akes 
kc-fovc *tWm^S 
y 七 s 七 3 v • 七 ed. 


s 


• ，” ou we V 

bcch ^ bu{ adds 
cx ^ devils. 


Todd and ^iwas Poq Vook version 2.0 

What the Poor Poes 


Primary Actor: Fido 

Secondary Actors: Todd and (r\m 

Pre - condition: Fido is inside, and weeds to use the restroom. 

&oal: Fido has used the bathroom and is back inside the 
house, without Todd or &ina having to get up and open 
or close the dog door. 

Main Path 

1. Fido barks to be let out. 

2. Todd or (r\m hears Fido barking. 

炙 Todd or (rim presses the button on the remote control. 

4. The dog door opens. 

5. Fido goes outside. 

6. Fido does his business. 

7 Fido goes back inside. 

S. The door shuts automatically. 


l^yiw^ i h -the usc 
is -towav-ds 

^or^plishi^ this goal. 


Al-tcvv^a-tc ?a^s avc 
also tailed 
and *tW»s ^o\rma*t, 
avc \\sitd 1dcIo>m i\\t 
mdm pa*t^ steps. 


^=- 


Extewsiows 

6.1 The door shuts automatically. 

6.2 Fido barks to be let back inside. 

6 •多 Todd or (r\m hears Fido barking (again). 

6.4 Todd or (r\m presses the button on the remote control. 

6.5 The dog door opens (again). 


a^c ihc steps 
^omn -the 3lic\ry)3ic 

P 十， bu+ thcyVc just 

listed scpav-atcly. 


All o-f these use £dses say ihc sst^e 七 h’m 今 … 
i 七 ’s up 七 0 you (dhd pv-ob^oly your boss) b> 
dtt\dc v/hidK -format, works bes-t -for you. 
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leftovers 


Awti patterns 


We’ve talked a lot in this book about design patterns, and 
described them this way: 


Design Patterns 

Design patterns are proven solutions to 
particular types of problems, and help us 
structure our own applications in ways 
that are easier to understand, more 
maintainable, and more flexible. 


But there’s another type of pattern you should know about, 
called an anti-pattern: 


Design patterns 
kelp you recognize 
and implement 

GOOD solutions to 

conimon problems. 


Anti Patterns 

Anti-patterns are the reverse of design 
patterns: they are common BAD solutions 
to problems. These dangerous pitfalls 
should be recognized and avoided. 


Anti patterns turn up when you see the same problem get solved 
the same way, but the solution turns out to be a BAD one. For 
example, one common anti pattern is called “Gas Factory”，and 
refers to designs that are overly complex, and therefore not very 
maintainable. So you want to work to avoid the Gas Factory in 
your own code. 


Anti patterns are 


about 


• • 


recognizing 


and avoicting 

BAD solutions to 

conimon problems. 


^ f -oi ^ 

th,s up/ Ai youv^ hcxi 

dcvclop^cht 
be suv-c io 
^ ^oid 

the qas 
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crc cards 


# 4. CRC cards 


CRC stands for Glass, Responsibility, Collaborator. These cards are 
used to take a class and figure out what its responsibility should be, 
and what other classes it collaborates with. 

CRC cards are typically just 3x5 index cards, with each individual 
card representing a class. The card has two columns: one for the 
responsibilities of the class, and another for other classes that are 
collaborators, and used to fulfill those responsibilities. 


This tlass is the class 

yo“ 代 dctc^ihi h a 

^cspohsibili-tics -fov-. 


Class ： BarkRedo^i 




PcSCriptiOd: This dass is -the 'm*tc\r-fadc *to -the ba\rk \rc^o^i*tioir\ ha\rd>wa\rc- 


Responsibilities ： 

Name 

Tell 七 lie doo^r b> open 


Collaborator 


Po^Poov 


Lis*t 
job "bWis tlass 
y>ccds bo do. 


"theme av-c 
0 士 hem desses 
Solved is ihis 

j ob ，W ih cnt ih 

^ IS 匕 olumh. 


Be suve you wvi-tc 
dovm thihgs that 
七 his dl^ss docs oh i*ts 

owh, 3s well 3s -things 

i 七 dolldbov*d^cs wi 七 h 
classes oh. 


Cl^SS, Po^Door 

l?6SCnpti0d: Rcp\rcsci^*ts -the physical do^ door. This provides By\ 
ho the iiavdlwave 七 1 ^七 ad-bually 乙 o 灼 ^brols -bhe doov- 

Responsibilities ： 


Name 


Collaborator 



Oycr\ 七 he door 

Nr 

Close 七 lie door 

X 


\ \ 


\\ 


V » s 6o\\aWaW 


1 heve b n 

^ov tV'ese- 
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leftovers 


CRC cards help implement the SRP 

You can use GRG cards to make sure your classes follow the Single 
Responsibility Principle. These go hand in hand with your SRP 
Analysis, as well: 


SRP Analysis for 

Automobile 


The ■ 

Au*bonr\obilc 

s*tar 七 [s] 

.itself. 

The ■ 

Au*bomobilc 

s*topCs3 

.itself. 

The ■ 

Automobile 

dhah^csTires 

.itself. 

The ■ 

Automobile 

driveCs] 

.itself. 

The ■ 

Automobile 

y/ashCes] 

.itself. 

The ■ 

Au*bomobilc 

dhcdkCsJ oil 

.itself. 

The 

Au*bor«obilc 

o\rtCs] oil 

itself. 



^ y o “ c 3 。七 a dass 

SCCrtnS {x> violate 
^ ^ you .a, use 
a CRC Wd "to 阶七 

ou "t whi^h classes 
should be doihj what 



Ahy tir^c you see 

如 ts' it’s probably 
十 the \rcspohsibili-ty 
° + "this class -to do a 

以 irbi h -task. 


Class ： AuWobile 

PeSCriptiOW: This dass \rcp\rcsc^*b a da\r a^d its \rcla*tcd -fu^*tioir\ali*ty 


Responsibilities： 



Name 

Collaborator 

£*tav-ts itscl-f. 


£*tops i*tsd-f. 


6fc{s tl\rcs 

McdKanid； Tiv-c 

6g-Ks <j\rivgy\ 

Dvivgy 

y/asKcd 

CavWasli, Att 伙 dairt 

^c*ts oil cMtcVtA 

McdKanid 

Rg^ovks oy \ oil Igvgls 



I^SH? 
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metrics and sequence diagrams 


巧 . Metrics 


Sometimes it’s hard to tell how solid your design really is, because design is such 
a subjective thing. That’s where metrics can help out: while they don’t provide 
a complete picture of your system, they can be helpful in pointing out strengths, 
weaknesses, and potential problems. You usually use software tools to take as input 
your class’s source code, and those tools then generate metrics based on your code 
and its design. 

These metrics are more than just numbers, though. For example, just counting the 
number of lines of code in your application is almost a total waste of time. It’s 
nothing but a number, and has no context (and also depends a lot on how you’re 
writing your code, something else we’ll talk about in this appendix). But if you count 
the number of defects per 1000 lines of code, then that becomes a useful metric. 


defect density 


C\r\ro\rs 


-fou^d \y\ toAt 


•botal Irncs o-f toAt / IOOO 


Jives you sor^c ic | ca 
how well youVe wi 仏”财 

l!i ^ S * ook olr dcsi 9 h 

pwble ⑽饮 9 


You can also use metric to measure things like how well you’re using abstraction in 
your code. Good design will use abstract classes and interfaces, so that other classes 
can program to those interfaces rather than specific implementation classes. So 
abstraction keeps one part of your code independent from changes to other parts 
of your code, at least to the degree that it’s possible in your system. You can use 
something called the abstractness metric to measure this: 



A = N. / N, 


li ⑽ mb ab 如冼 

Masses ^ a ㈣ 十 

module 70 ^ so-fW 


ov* 


\ is ihc iohl 


丁 Wis number will alv/ays be 

betv/e ⑼ o ar^d I. tt • 吵 e\r numbers 

mean mo^TC abs 七以 W be” 
uscd> loy/cv y\uw\bcv"S \rcpv-csc^*t 
less abs*t\radtior\. 


Packages that have lots of abstractions will have a higher value for A, and packages 
with less abstractions have a lower value for A. In general, you want to have each 
package in your software only depend on packages with a higher value for A. That 
means that your packages are always depending on packages that are more abstract; 
the result should be software that can easily respond to change. 


Robert MarU’s book tailed^ 
So^tv/av-c Pcvclopmc^ 
d lo*b move "these 00— 
v-cla*tcd mc*br»ts. 
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leftovers 


# 6. Sequence diagrams 

When we were working on the dog door for Todd and Gina, we developed 
several alternate paths (and one alternate path actually had an alternate 
path itself). To really get a feel for how your system handles these different 
paths, it’s helpful to use a UML sequence diagram. A sequence diagram 
is just what it sounds like: a visual way to show the things that happen in a 
particular interaction between an actor and your system. 


TW»s *»s adW 七 “ 
s*b3V"*tcd 


boxes y/i 七 h 
-the syst^. 
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state diagrams 


# 7. State diagrams 

You’ve already seen class diagrams and sequence diagrams. UML also 
contains a diagram called a state machine diagram or statechart 
diagram, which is usually just referred to as a state diagram. This 
diagram describes a part of your system by showing its various states, 
and the actions that cause that state to change. These diagrams are 
great for describing complex behaviors visually. 

State diagrams really come into play when you have multiple actions 
and events that are all going on at the same time. On the right page, 
we’ve taken just such a situation, and drawn a state diagram for how 
a game designer might use Gary’s Game System Framework. If game 
designers were going to use the framework, they might write a game 
that behaves a lot like this state diagram demonstrates. 
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unit testing 

# S. Unit testing 

In each chapter that we’re worked on an application, we’ve built 
“driver” programs to test the code, like SubwayTester and 
DogDoorSimulator. These are all a form of unit testing. We 

test each class with a certain set of input data, or with a particular 
sequence of method calls. 

While this is a great way to get a sense of how your application 
works when used by the customer, it does have some drawbacks: 

o You have to write a complete program for each usage of 
the software. 

❾ You need to produce some kind of output, either to the 

console or a file, to verify the software is working correctly. 

You have to manually look over the output of the test, each 
time its run, to make sure things are working correctly. 

o Your tests will eventually test such large pieces of 

functionality that you’re no longer testing all the smaller 
features of your app. 

Fortunately, there are testing frameworks that will not only allow 
you to test very small pieces of functionality, but will also automate 
much of that testing for you. In Java, the most popular framework 
is called JUnit (http://www.junit.org), and integrates with lots of 
the popular Java development environments, like Eclipse. 


ttere are no . 

Dumb Questions 


If the tests we wrote in the main part of the book made 
sure our software worked at a high level, why do we need more 
tests? Aren’t those enough to be sure our software works? 


The reason that you need both types of tests is because you’ll 
never be able to come up with scenarios that test every possible 
combination of features and functionality in your software. We're all 
human, and we all tend to forget just one or two strange situations 


Most of the tests we wrote really tested a particular scenario, 
such as opening the door, letting a dog out, having another dog bark, 
and then letting the owner’s dog back in. Unit tests, and particular the 
tests we’re talking about here, are far more granular. They test each 
class’s functionality, one piece at a time. 


now and then. 

With tests that exercise each individual piece of functionality in your 
classes, you can be sure that things will work in any scenario, even if 
you don’t specifically test that scenario. It’s a way to make sure each 
small piece works, and one that lets you assume pretty safely that 
combining those small pieces will then work, as well. 
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What a test case looks like 

A test case has a test method for each and every piece of functionality 
in the class that it’s testing. So for a class like DogDoor, we’d test 
opening the door, and closing the door. JUnit would generate a test 
class that looked something like this: 


import junit.framework.TestCase; 


* This test case tests the operation of the dog door by using the 

* remote button. 

public class RemoteTest extends TestCase 


assev* 七丁 ' 

C \^ t tVs -to see 

should 

• m tw»s tasc. 


public void testOpenDoor() 
{ 


DogDoor door = new DogDoor (); 
Remote remote = new Remote(door); 
remote.pressButton (); 
assertTrue(door.isOpen ()); 


TcsiCasc is JUhit s base dass 
士 。 \r "tes-tihj so-f*tw3V"C- 

TV>cvc s a 


asscv-tFalscO 

匕 haks a 

method *to 
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public void testCloseDoor () { 

DogDoor door = new DogDoor (); 
Remote remote = new Remote(door); 

remote.pressButton(); ^ - 

try { 


Thread.currentThread() •sleep (6000) 
catch ( 工 nterruptedException e) { 
fail (''interrupted thread^); 


assertFalse(door.isOpen()) 


This method tes-ts -Pov 

、 - - the doo\r 

dosmg, \rathc\r tholh just 
dooir.doseO, whidh 
ish 七 how the doo\r is 
usually used- 


Test your code m context 

Notice that instead of directly testing the DogDoor ’s open () and 
close () methods, this test uses the Remote class, which is how 
the door would work in the real world. That ensures that the tests are 
simulating real usage, even though they are testing just a single piece of 
functionality at a time. 

The same thing is done in testCloseDoor (). Instead of calling 
the close () method, the test opens the door with the remote, waits 
beyond the time it should take for the door to close automatically, and 
then tests to see if the door is closed. That’s how the door will be used, 
so that’s what should be tested. 
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# 9. Coding standards and readable code 


Reading source code should be a lot like reading a book. You should 
be able to tell what’s going on, and even if you have a few questions, it 
shouldn’t be too hard to figure out the answers to those questions if you 
just keep reading. Good developers and designers should be willing to 
spend a little extra time writing readable code, because it improves the 
ability to maintain and reuse that code. 

Here’s an example of a commented and readable version of the 
DogDoor class we wrote back in Chapters 2 and 3. 


* This class represents the interface to the real dog door. 

* 



* @author Gary Pollice 

* ©version Aug 11, 2006 

" 

public class DogDoor 


// the number of open commands in progress 
private int numberOfOpenCommands = 0; 


help people 

ihc Codt, ahd also be 


boolean doorlsOpen = false; 

/ 'k'k 

* @return true if the door is open 

V 

public boolean isOpen () ^ 

{ 

return doorlsOpen; 



Mcihod 3hd v^Hdble 
easy *to dc^iphcv-. 
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3 single method 
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* Open the door and then, five seconds later, close it. 

V 

public void open() 

{ 

// Code to tell the hardware to open the door goes here 
doorlsOpen = true; 
numberOfOpenCommands++; 

TimerTask task = new TimerTask() { 

public void run() { 

if (--numberOfOpenCommands == 0) { 

// Code to tell the hardware to close the door goes here 
doorlsOpen = false; 


Timer timer = new Timer(); 
timer.schedule(task, 5000); 


sta-tewc^-b 

a^-t ? c^l 7 c\tar avc 

bo 
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ftrcat software is more thaw just 
working code 


Many developers will tell you that code standards and formatting are 
a big pain, but take a look at what happens when you don’t spend any 
time making your code readable: 


public class DogDoor 
{ 

private int noc = 0; 
boolean dio = false; 


|s ( 0 at all V>cvc •• 、七 匕 

L develop^ 

whai "these 

enables … 


public boolean returndio( ) { return dio; } 


public void do_my_j ob( 

{ _ 
dio = true; 
noc++; 



…饮 these wc 七 hods. 
TV y\awcs av-c ”。七 a 七 
all dcs ㈣ 七 Wc. 


TimerTask tt = new TimerTask() { 

public void run () { 

if (--noc —. 0) dio — false; 



Timer t = new Timer(); 
t.schedule(tt, 5000); 


"TKc o-P 
mdchtatioh ahd 

ihmgs cvch hav-dev- 
"to uhdev-s-t^hd- 


From a purely functional point of view, this version of DogDoor works 
just as well as the one on the last page. But by now you should know 
that great software is more than just working code — it’s code that is 
maintainable, and can be reused. And most developers will not want to 
maintain or reuse this second version of DogDoor; it’s a pain to figure 
out what it does, or where things might go wrong — now imagine if 
there were 10,000 lines of code like this, and not just 25 or so. 


Writing reactatle cocte makes tkat code 
easier to maintain and reuse, lor you 
anct otker developers. 
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# 10. Rcfactoriwg 


Refactoring is the process of modifying the structure of your code 
without modifying its behavior. Refactoring is done to increase the 
cleanness, flexibility, and extensibility of your code, and usually is 
related to a specific improvement in your design. 

Most refactorings are fairly simple, and focus on one specific design 
aspect of your code. For example: 


public double getDisabilityAmount() { 

// Check for eligibility 
if (seniority < 2) 
return 0; 

if (monthsDisabled > 12) 
return 0; 
if (isPartTime) 
return 0; 

// Calculate disability amount and return it 

} 

While there’s nothing particularly wrong with this code, it’s not as 
maintainable as it could be. The getDisabilityAmount () 
method is really doing two things: checking the eligibility for disability, 
and then calculating the amount. 

By now, you should know that violates the Single Responsibility 
Principle. We really should separate the code that handles eligibility 
requirements from the code that does disability calculations. So we can 
refactor this code to look more like this: 


Relactoring 
cltanges tlie 
internal structure 
ol your code 

WITHOUT 

aWecting your 
code’s tekavion 


public double getDisabilityAmount() { 

// Check for eligibility ^ - -- 

if (isEligibleForDisability()) { 

// Calculate disability amount and return it 
} else { 
return 0; 




Now, if the eligibility requirements for disability change, only the 

isEligibleForDisability () methods needs to change — and 
the method responsible for calculating the disability amount doesn’t. 

Think of refactoring as a checkup for your code. It should be an 
ongoing process, as code that is left alone tends to become harder and 
harder to reuse. Go back to old code, and refactor it to take advantage 
of new design techniques you’ve learned. The programmers who have 
to maintain and reuse your code will thank you for it. 


574 Appendix I 




appendix ii ： Welcome to objectVille 



eaking the 
Language of 00 


It says here that you want 
to change my composition to 
aggregation, add some delegation, 
and that I’m not well-encapsulated, 
rm totally lost, and I think I might 
even be insulted! 成 


Get ready to take a trip to a foreign country, it s time 


to visit Objectville, a land where objects do just what they’re supposed 


to, applications are all well-encapsulated (you’ll find out exactly what that 


means shortly), and designs are easy to reuse and extend. But before we 


can get going, there are a couple of things you need to know first, and a few 


language skills you’re going to have to learn. Don’t worry, though, it won’t 
take long, and before you know it, you’ll be speaking the language of 00 like 
you’ve been living in the well-designed areas of Objectville for years. 


this is an appendix 
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a care package for you 

Welcome to Objectville 

Whether this is your first trip to Objectville, or you’ve visited 
before, there’s no place quite like it. But things are a little 
different here, so we’re here to help you get your bearings before 
you dive into the main part of the book. 


Welcome to Objectville! I picked 
up a few things I thought you might 
need to help make you comfortable 
right away. Enjoy! 
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welcome to objectville 


UML and class diagrams 

We’re going to talk about classes and objects a lot in this book, but it’s 
pretty hard to look at 200 lines of code and focus on the big picture. 

So we’ll be using UML, the Unified Modeling Language, which is a 
language used to communicate just the details about your code and 
application’s structure that other developers and customers need, 
without getting details that aren’t necessary. 


TWis »s \\o^i 70U s\\o^ a 
diass rn a tlass 
That’s 从 at 

UML 70 U 
dc*ta'»U about Hasses 
• m a 代 Vitat’ow 

TV^csc avc 

vav-»aWcs 

Ut^ o^c V^as a 

a^d * 0 ^ a 切 ? e 

toW 

ih c - 
^ihods ^ ihc 

^ E^h has 
s ^ ih eh 

^od ^ 

^ 3 iyp c 

4 ^ .o/o, yPC 


TVis is -the hdme o( 

七 he 匕 lass. diw^ys 

ih told, at -the -top o-P 

the dass 



J} ，s ,ihC 处 P 的 i es 

r hc 咖饮 tables 

^eihods of 

tnc dsss. 



A diass makes vt WII 7 cq 

匕 sw 如 h ? \ 6 Wc ： YOU 63V. cas.lv 
七 ell 一七 a — doesata — 二 
n/ou e 心 ! cavc ou 七七 vayn 

ay^d/or r^c^ods \( .-t ^el ? s YOU 


f^harpen your pencil 


Write the skeleton for the Airplane class. 

Using the class diagram above, see if you can write the basic skeleton for 
the Airplane class. Did you find anything that the class diagram leaves out? 
Write those things in the blanks below: 
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coding from a class diagram 


Sharpen your pencil - 

answers 


Write the skeleton for the Airplane class. 

Using the class diagram on page 577, you were supposed to write 
the basic skeleton for the Airplane class. Here’s what we did: 


TV^c dlass 

s? ccd should ” 


public class Airplane 

private int speed; 

public Airplane() { 

} 


H ^ou-t a ih 
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public void setSpeed(int speed) 
this.speed = speed; 


public int getSpeed() 
return speed; 


The dlass d\ayra^ did^i 

tell us what this method 
did ., wc sorv\e 
assumptiohs, but wc 
be su\rc i-P this dode is 
⑽ lly what was m-tchdcd. 




So the class diagram isn’t a very 
complete representation of a class, is it? 


A! No, but it’s not meant to be. Class 
diagrams are just a way to communicate 
the basic details of a class’s variables and 
methods. It also makes it easy to talk about 
code without forcing you to wade through 
hundreds of lines of Java, or C, or Perl. 



e no . 

Questions 


There's nothing wrong with your 
own notation, but it can make things harder 
for other people to understand. By using 
a standard like UML, we can all speak the 
same language and be sure we’re talking 
about the same thing in our diagrams. 


So who came up with this UML 
deal, anyway? 


I’ve got my own way of drawing 
classes; what’s wrong with that? 


A! The UML specification was 
developed by Rational Software, under the 
leadership of Grady Booch, Ivar Jacobson, 
and Jim Rumbaugh (three really smart 
guys). These days it’s managed by the 
OMG, the Object Management Group. 


Sounds like a lot of fuss over that 
simple little class diagram thing. 


n. UML is actually a lot more than 
that class diagram. UML has diagrams for 
the state of your objects, the sequence of 
events in your application, and it even has 
a way to represent customer requirements 
and interactions with your system. And 
there’s a lot more to learn about class 
diagrams, too. 

At this point, though, you just need the 
basics on page 577. We'll talk about other 
things you can show in a class diagram, 
and other types of diagrams, when we need 
them later in the book. 
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Next up: mheritance 

One of the fundamental programming topics in Objectville is 
inheritance. That’s when one class inherits behavior from another 
class, and can then change that behavior if needed. Let’s look at how 
inheritance works in Java; it’s similar in other languages, too: 
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public class Jet extends Airplane 




private static final int MULTIPLIER = 2 

public Jet() { 

super(); 


public void setSpeed(int speed) 

super.setSpeed(speed * MULTIPLIER) 


^ Ai 吓 U e . 



public void accelerate () { 

super.setSpeed(qetSpeed() 
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Inheritance lets you build classes 
based on other classes, and avoid 
duplicating and repeating code. 
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pool puzzle 



Paa] Puzz]c 



Your job is to take code snippets from 
the pool below and place them into 
the blank lines in the code 
you see on the right. 

You may use the same 
snippet more than once, 
and you won’t need 
to use all the snippets. 
Your goal is to create a 
class that will compile, run, 
and produce the output listed. 


Output: 

I File Edit Window Help LeavingOnAJetplane 


% java FlyTest 
212 
844 
1688 
6752 
13504 
27008 
1696 


public class FlyTest { 

public static void main(String[] args) { 

Airplane biplane = new Airplane(); 

biplane . setSpeed (_); 

System. out. print In (_); 

Jet boeing = new Jet(); 

boeing. setSpeed (_); 

System. out. print In (_); 


while ( 


System. out. println (_); 

if (_ > 5000) { 

_(_ * 2 ); 

} else { 


System.out.println( 




- ► Solution on pa^e 588 
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Awd polymorphism, too. 


tt 


Polymorphism is closely related to inheritance. When 
one class inherits from another, then polymorphism allows a 

subclass to stand in for the superclass. 


*bv/o classes. 
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getSpeed(): int 


accelerate() 

setSpeed(int) 
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Airplane plane = new Airplane(); 
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Airplane plane = new Airplane(); 
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扣 y d i*ts subclasses. -— 


Airplane plane = 
Airplane plane = 
Airplane plane = 


new Airplane(); 
new Jet(); 


new Rocket(); 
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What’s so useful about polymorphism? 


You can write code that works on the superclass, like 
Airplane, but will work with any subclass type, like Jet or 
Rocket. So your code is more flexible. 


flexible. 


I still don’t get how polymorphism makes my code 


Well, if you need new functionality, you could write a new 
subclass of Airplane. But since your code uses the superclass, 
your new subclass will work without any changes to the rest of our 
code! That means your code is flexible and can change easily. 
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Last but wot least: encapsulation 

Encapsulation is when you hide the implementation of a 
class in such a way that it is easy to use and easy to change. It 
makes the class act as a black box that provides a service to its 
users, but does not open up the code so someone can change 
it or use it the wrong way. Encapsulation is a key technique in 
being able to follow the Open-Closed principle. Suppose we 
rewrote our Airplane class like this: 

public class Airplane { 



\/\/c w\3(lc 

灼 all vav'ts 

0^ aw 

— 加卿 


public int speed; 
public Airplane() { 


public void setSpeed(int speed) 
this.speed = speed; 

} 

public int getSpeed() { 

return speed; 


Now anyone can set the speed directly 

This change means that the rest of your app no longer has to call 
setSpeed () to set the speed of a plane; the speed variable can be 
set directly. So this code would compile just fine: 


Encapsulation 
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public class FlyTest2 { 

public static void main(String[] args) { 

Airplane biplane = new Airplane(); 

biplane. speed = 212; - - - - --^ 

System. out. println (biplane. speed) ; ^^ 
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So whaf s the big deal? 

Doesn’t seem like much of a problem, does it? But what happens if 
you create a Jet and set its speed like this: 


Us — 上七 


public class FlyTest3 { 

public static void main(String[] args) 
Jet j etl new Jet (); 
j etl.speed = 212 


'orn 


System.out.printIn(j etl.speed); 


Sihde Jet ihhc\r*rts -fv< 
Aiv*plahC, you use "the 
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s^dass just like it was 
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Jet j et2 = new Jet (); 

Ws'rnj Jet with x j et2 • setSpeed (212); 

Chdapsulatioh ^ ( System. out. print In (j et2 . get Speed ()); 、 

} TW、s 二 
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arpen your pencil 


What’s the value of encapsulating your data? 

Type in, compile, and run the code for FlyTest3.java, shown above. What 
did your output look like? Write the two lines of output in the blanks below: 


Speed of jetl: 
Speed of jet2: 


What do you think happened here? Write down why you think you got the 
speeds that you did for each instance of Jet: 


Finally, summarize what you think the value of encapsulation is: 
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the value of encapsulation 
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What’s the value of encapsulating your data? 

Type in, compile, and run the code for FlyTest3.java shown above. What 
did your output look like? Write the two lines of output in the blanks below: 


Speed of jetl: 
Speed of jet2: 


212 


424 



What do you think happened here? Write down why you think you got the 
speeds that you did for each instance of Jet: 

In the Jet class, setSpeedH takes the value supplied, and multiplies 

it by two before setting the speed of the jet. When wc set the 

speed variable manually, it didn't get multiplied by two. 

Finally, summarize what you think the value of encapsulation is: 

Encapsulation protects data from being set iw m improper way. With 

encapsulated data, any calculations or checks that the class does on 

the data are preserved, since the data ca^t be accessed directly. 
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Questions 


So encapsulation is all about 
making all your variables private? 


So encapsulation is really about 
protecting your data, right? 


No, encapsulation is about 
separating information from other parts of 
your application that shouldn’t mess with 
that information. With member variables, 
you don’t want the rest of your app directly 
messing with your data, so you separate 
that data by making it private. If the data 
needs to be updated, you can provide 
methods that work with the data responsibly, 
like we did with the Airplane class, using 
getSpeed () and setSpeed (). 


A: Actually, it’s even more than 
that! Encapsulation can also help you 
separate behavior from other parts of your 
application. So you might put lots of code in 
a method, and put that method in a class; 
you’ve separated that behavior from the 
rest of your application, and the app has to 
use your new class and method to access 
that behavior. It’s the same principles as 
with data, though: you’re separating out 
parts of your application to protect them 
from being used improperly. 


So are there other ways to use 
encapsulation besides with variables? 


Wow, I’m not sure I’m following 
all of this. What do I need to do? 


Absolutely. In fact, in Chapter 1, 
well be looking at how you can encapsulate 
a group of properties away from an object, 
and make sure that the object doesn’t use 
those properties incorrectly. Even though 
well deal with an entire set of properties, it’s 
still just separating a set of information away 
from the rest of your application. 


A! Just keep reading. Make sure you 
understand the exercise solutions on page 


584, and you’re ready for Chapter 1. We’ll 
spend a lot more time on all of these 00 
principles and concepts, so don’t feel like 
you need to get everything down perfectly 
at this point. 


Encapsulation 
separates 
your data 
Irom your 
app’s 
teliavior. 


Tken you can 
control kow 


eaclt part is 
usect hy tke 
rest ol your 
application. 
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reviewing the basics 


Already gone through 
everything? Then you’re definitely 
ready for the rest of this book. And 
welcome again to the well-designed 
part of Objectville... we love it here, 
rm sure you will, too. 


r- BULLET POINT 



■ UML stands for the Unified 
Modeling Language. 

■ UML helps you communicate 
the structure of your application 
to other developers, customers, 
and managers. 

■ A class diagram gives you an 
overview of your class, including 
its methods and variables. 

■ Inheritance is when one class 
extends another class to reuse 
or build upon the inherited 
class’s behavior. 

■ In inheritance, the class being 
inherited from is called the 
superclass; the class that is 
doing the inheritance is called 
the subclass. 

■ A subclass gets all the behavior 
of its superclass automatically. 


■ A subclass can override its 
superclass’s behavior to change 
how a method works. 

■ Polymorphism is when a 
subclass “stands in" for its 
superclass. 

■ Polymorphism allows your 
applications to be more flexible, 
and less resistant to change. 

■ Encapsulation is when you 
separate or hide one part of your 
code from the rest of your code. 

■ The simplest form of 
encapsulation is when you make 
the variables of your classes 
private, and only expose that 
data through methods on the 
class. 

■ You can also encapsulate 
groups of data, or even 
behavior, to control how they are 
accessed. 
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OOA&D Cross 

Take a moment to review the concepts in this appendix, 
and then you’re ready to step firmly into the world of 
analysis, design, 00 programming, and great software. 



Across 

3. TWfi k when a can iubitil'uta fcr 

ptl 

m. diugrumS d 口 n 1 1 sUdw delojiJsi uboul this 

part of our class. 

5. A That inherits from nnolher class is 
tKii. 

EflcapSifla+bn Jets ya-u do tKii t* 
inf flrmat^ian. 

7. A cFaSS Kha^ i3 inherited from i3 calJcd fhr'i. 



1 ， A na-ther term far ^ncapsuJatian k £eparafiQin 
of th'ia, 

^olymorphiiirni hdpi mukc yuur ciadc 

4 . Use this kind of diagram to ovoid wodin^ 
through IcrtS of code. 
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pool puzzle solution 




Paa] Puzz]c 



Your job was to take code snippets 
from the pool below, and place them 
into the blank lines in the code you see 
on the right. You may use the same 
snippet more than once, and you won’t 
need to use all the snippets. Your goal 
was to create a class that will compile, 
run, and produce the output listed. 


Output: 

I File Edit Window Help LeavingOnAJetplane 


% java FlyTest 
212 
844 
1688 
6752 
13504 
27008 
1696 


public class FlyTest { 

public static void main(String[] args) { 

Airplane biplane = new Airplane(); 
biplane.setSpeed (212); 

System, out. print in ( biplane. getSpeed()) ; 

Jet boeing = new Jet(); 
boeing.setSpeed (422) ; 

System, out. print in ( boeing. getSpeed()); 
int x = 0 ； 
while (x<4) { 
boeing. accelerate 。； 

System. out. print in ( boeing . getSpeed()); 
if ( boeing.getSpeed() > 5000) { 

biplane.setSpeed (biplane.getSpeed() * 2 ); 

} else { 

boeing. accelerate 。； 

} 

x ++； 

} 

System, out. print in ( biplane. getSpeedQ)； 


ouv -to 

yool 
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